extended operator classes vs. type interfaces
in [PgSql]
|
Prev: a faster compression algorithm for pg_dump
Next: [HACKERS] How to modify default Type (TSQuery) behaviour?
From: Jeff Davis on 9 Apr 2010 17:45 On Fri, 2010-04-09 at 11:14 -0400, Robert Haas wrote: > > range of integers with increment y, if x<>y? Maybe the increment step and > > continuous/discrete could be typmods. > > Nope, not enough bits available there. I think the problem is deeper than that. Typmods aren't carried along as part of the result of a function call, so typmod is not really a part of the type at all -- it's more a property of the column. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jeff Davis on 9 Apr 2010 17:49 On Thu, 2010-04-08 at 22:29 -0400, Robert Haas wrote: > 1. knngist wants to use index scans to speed up queries of the form > SELECT ... ORDER BY <column> <op> <constant> (as opposed to the > existing machinery which only knows how to use an index for SELECT ... > ORDER BY <column>). > 2. Window functions want to define windows over a range of values > defined by the underlying data type. To do this, we need to define > what addition and subtraction mean for a particular data type. > 3. Jeff Davis is interested in implementing range types. When the > underlying base type is discrete, e.g. integers, you can say that > [1,3] = [1,4), but only if you know that 3 and 4 are consecutive (in > that order). To give some context, I started a thread a while ago: http://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php Tom provided some interesting suggestions in that thread, but I'm not sure they would work for #1 or #2. > It may or may not be worth building the concept of a unit > increment into the type interface machinery, though: one could imagine > two different range types built over the same base type with different > unit increments - e.g. one timestamp range with unit increment = 1s, > and one with unit increment = 1m. Under the first type [4pm,5pm) = > [4pm,4:59:59pm], while under the second [4pm,5pm) = [4pm,4:59pm]. Right. Part of the interface could be a unit() function, and that can return whatever you want. I was originally thinking about it in terms of next() and prev(), but you could build those from +, -, and unit(). Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 9 Apr 2010 18:00 On Fri, Apr 9, 2010 at 5:49 PM, Jeff Davis <pgsql(a)j-davis.com> wrote: >> It may or may not be worth building the concept of a unit >> increment into the type interface machinery, though: one could imagine >> two different range types built over the same base type with different >> unit increments - e.g. one timestamp range with unit increment = 1s, >> and one with unit increment = 1m. Under the first type [4pm,5pm) = >> [4pm,4:59:59pm], while under the second [4pm,5pm) = [4pm,4:59pm]. > > Right. Part of the interface could be a unit() function, and that can > return whatever you want. > > I was originally thinking about it in terms of next() and prev(), but > you could build those from +, -, and unit(). The advantage of specifying a + and a - in the type interface is that the unit definition can then be specified as part of the type declaration itself. So you can do: CREATE TYPE ts_sec AS RANGE OVER timestamp (UNIT = '1s'); CREATE TYPE ts_min AS RANGE OVER timestamp (UNIT = '1m'); All of the stuff about defining + and - is hidden from the user - it's part of the type interface, which is pre-created. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Nathan Boley on 9 Apr 2010 19:18 > The advantage of specifying a + and a - in the type interface is that > the unit definition can then be specified as part of the type > declaration itself. So you can do: > > CREATE TYPE ts_sec AS RANGE OVER timestamp (UNIT = '1s'); > CREATE TYPE ts_min AS RANGE OVER timestamp (UNIT = '1m'); > > All of the stuff about defining + and - is hidden from the user - it's > part of the type interface, which is pre-created. > The disadvantage is that it does not permit irregularly spaced units. -Nathan -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 9 Apr 2010 19:53
On Fri, Apr 9, 2010 at 7:18 PM, Nathan Boley <npboley(a)gmail.com> wrote: >> The advantage of specifying a + and a - in the type interface is that >> the unit definition can then be specified as part of the type >> declaration itself. So you can do: >> >> CREATE TYPE ts_sec AS RANGE OVER timestamp (UNIT = '1s'); >> CREATE TYPE ts_min AS RANGE OVER timestamp (UNIT = '1m'); >> >> All of the stuff about defining + and - is hidden from the user - it's >> part of the type interface, which is pre-created. > > The disadvantage is that it does not permit irregularly spaced units. True. The only types I can think of that have irregularly spaced units would be things based on floating points, and I was assuming that people would only want continuous intervals on those. If someone really wants to be able to deduce that [1.0,3.0) = [1.0,3.0-epsilon), then we need a different design. But I find it hard to believe that's very useful. Maybe you feel otherwise? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |