extensible enum types
in [PgSql]
|
From: Andrew Dunstan on 18 Jun 2010 18:33 Joseph Adams wrote: > Also, I can't seem to find the original debates from when enums were > implemented. Does anyone have a link to that thread in the archives? > Thanks. > Start here <http://archives.postgresql.org/pgsql-hackers/2006-08/msg00979.php> cheers andrew -- 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: Alvaro Herrera on 18 Jun 2010 18:36 Excerpts from Joseph Adams's message of vie jun 18 18:17:50 -0400 2010: > Couldn't enum_eq just use get_fn_expr_argtype to determine the type of > enum input rather than rely on it being stored in the value (either > implicitly via OID or explicitly as a word half)? > > Also, I can't seem to find the original debates from when enums were > implemented. Does anyone have a link to that thread in the archives? Probably around here http://archives.postgresql.org/pgsql-patches/2006-12/msg00099.php -- Álvaro Herrera <alvherre(a)commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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: Tom Lane on 18 Jun 2010 18:53 Joseph Adams <joeyadams3.14159(a)gmail.com> writes: > Couldn't enum_eq just use get_fn_expr_argtype to determine the type of > enum input rather than rely on it being stored in the value No. Support functions have to work in many contexts where there is no "side channel" such as get_fn_expr_argtype. What's more, it's very difficult to provide a side channel without creating security holes. We used to think it was OK for output functions to rely on a type OID passed separately from the actual value, but that's insecure: http://archives.postgresql.org/pgsql-hackers/2005-04/msg00998.php regards, tom lane -- 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: Andrew Dunstan on 18 Jun 2010 19:59 Tom Lane wrote: >> And how would it be per data-type? >> > > Well, there'd be two kinds of enums, just as you were saying before. > I'm not sure how we'd expose that to users exactly, or whether there > could be provisions for switching a type's behavior after creation. > > > I'd be a whole lot happier if we didn't have to do that. I've been trying to wrack my brain for some clever way to avoid it (so far without success). cheers andrew -- 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: Andrew Dunstan on 19 Jun 2010 14:58
Tom Lane wrote: > Andrew Dunstan <andrew(a)dunslane.net> writes: > >> Tom Lane wrote: >> >>> Insert a sort order column into pg_enum, and rearrange the values in >>> that whenever the user wants to add a new value in a particular place. >>> You give up cheap comparisons in exchange for flexibility. I think lots >>> of people would accept that tradeoff, especially if they could make it >>> per-datatype. >>> > > >> But I'm not happy about giving up cheap comparison. >> > > I don't think it would be all that bad. We could teach typcache.c to > cache the ordering data for any type that's in active use. It'd > certainly be a lot more expensive than OID comparison, but perhaps not > worse than NUMERIC comparisons. > > > Another thought: could we add a column to pg_type with a flag that's true if the oids are in sort order? Then the comparison routines could just look that up in the type cache and if it's true (as it often will be) just return the oid comparison. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |