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: Robert Haas on 9 Apr 2010 13:19 On Fri, Apr 9, 2010 at 1:13 PM, Kevin Grittner <Kevin.Grittner(a)wicourts.gov> wrote: > As it is de rigueur for someone to escalate the proposed complexity > of an idea by at least one order of magnitude, and everyone else has > fallen down on this one: ;-) Gee, thanks for filling in? > I've often thought that if we rework the type system, it would be > very nice to support a concept of hierarchy. If you could > "subclass" money to have a subclass like assessable, which in turn > has subclasses of fine, fee, restitution, etc. you could then > automatically do anything with a subclass which you could do with > the superclass, and support such things as treating the sum of > various classes as the lowest common subclass. It seems like this > sort of approach, if done right, might allow some easier way to > establish sensible operations between types (like distance / speed = > time or speed * time = distance). > > Just a thought.... I dowanna rework the type system. I'm not even 100% sure I want to implement what I actually proposed. I do want to find out if people think the framework makes sense and whether it's the right way forward for those projects that need these features. What you're proposing here sounds suspiciously like something that should be handled by creating domains - but in any case it's almost entirely unrelated to what I was talking about. ....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: "Kevin Grittner" on 9 Apr 2010 13:50 Robert Haas <robertmhaas(a)gmail.com> wrote: > I dowanna rework the type system. I'm not even 100% sure I want > to implement what I actually proposed. I do want to find out if > people think the framework makes sense and whether it's the right > way forward for those projects that need these features. What you proposed sounds like it would be cleaner and less work than further perverting the index system as a source of information about types or hard-coding knowledge anywhere else. > What you're proposing here sounds suspiciously like something that > should be handled by creating domains Not really. Unless I've missed something domains are a single-level layer over a data type. I find them very useful and use them heavily, but the standard implementation is rather limited. Perhaps that would be the area to add the functionality I suggested, though. I'm totally at the hand-waving stage on it, with no concrete ideas. I just thought that if you were adding more type information, oriented aournd the types themselves rather than index AMs, some form of inheritence might fit in gracefully. > in any case it's almost entirely unrelated to what I was talking > about. OK -Kevin -- 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: Yeb Havinga on 9 Apr 2010 16:01 Robert Haas wrote: > On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga <yebhavinga(a)gmail.com> wrote: > >> .. I now see the example of different ranges in your original mail with >> different unit increments. Making that more general so there could be >> continuous and discrete ranges and for the latter, what would the increment >> be.. OTOH is a range of integers with increment x a different type from >> 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. This is fundamentally why the > typid/typmod system is so broken - representing a type as a fixed size > object is extremely limiting. A fixed size object that MUST consist > of a 32-bit unsigned OID and a 32-bit signed integer is even more > limiting. Fortunately, we don't need to solve that problem in order > to implement range types: we can just have people explicitly create > the ones they need. This will, for example, avoid creating ranges > over every composite type that springs into existence because a table > is created, even though in most cases a fairly well-defined range type > could be constructed. > Ok, no typmod, not default extra types for base types, but the concept of an still there is one aspect of ranges (may I say intervals?) of 'things' is something generic, and code to handle intervals of things could be shared between datatype implementations. A way to have generic support without automatic new types could be with something that looks like: What about CREATE TYPE ivl_int AS INTERVAL OF integer; SELECT '[1;2]'::ivl_int; etc regards, Yeb Havinga -- 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 16:36 On Fri, Apr 9, 2010 at 4:01 PM, Yeb Havinga <yebhavinga(a)gmail.com> wrote: > Robert Haas wrote: >> >> On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga <yebhavinga(a)gmail.com> wrote: >> >>> >>> .. I now see the example of different ranges in your original mail with >>> different unit increments. Making that more general so there could be >>> continuous and discrete ranges and for the latter, what would the >>> increment >>> be.. OTOH is a range of integers with increment x a different type from >>> 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. This is fundamentally why the >> typid/typmod system is so broken - representing a type as a fixed size >> object is extremely limiting. A fixed size object that MUST consist >> of a 32-bit unsigned OID and a 32-bit signed integer is even more >> limiting. Fortunately, we don't need to solve that problem in order >> to implement range types: we can just have people explicitly create >> the ones they need. This will, for example, avoid creating ranges >> over every composite type that springs into existence because a table >> is created, even though in most cases a fairly well-defined range type >> could be constructed. >> > > Ok, no typmod, not default extra types for base types, but the concept of an > still there is one aspect of ranges (may I say intervals?) of 'things' is > something generic, and code to handle intervals of things could be shared > between datatype implementations. A way to have generic support without > automatic new types could be with something that looks like: > > What about > CREATE TYPE ivl_int AS INTERVAL OF integer; > > SELECT '[1;2]'::ivl_int; > etc Yeah, that's how it has to work, I think. ....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: Jeff Davis on 9 Apr 2010 17:34
On Fri, 2010-04-09 at 12:50 -0500, Kevin Grittner wrote: > I just thought that if you were adding more type information, > oriented aournd the types themselves rather than index AMs, some form > of inheritence might fit in gracefully. There are already some specific proposals for inheritance in database theory literature. For instance: "Databases, Types, and the Relational Model" by C.J. Date addresses inheritance explicitly (and the appendices have some interesting discussion). I'm not sure how compatible it is with SQL, though; and I am not very optimistic that we could accomplish such a restructuring of the type system while maintaining a reasonable level of backwards compatibility. Either way, I think it's a separate topic. Two types that are not related by any subtype/supertype relationship (like strings and ints) can conform to the same interface (total ordering); while the very same type can conform to two different interfaces. 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 |