extensible enum types
in [PgSql]
|
From: Bruce Momjian on 23 Jun 2010 17:57 Tom Lane wrote: > Andrew Dunstan <andrew(a)dunslane.net> writes: > > Robert Haas wrote: > >> I like the idea of being able to modify enums on the fly, but I'm > >> skeptical of an implementation that won't always work. Maybe it's > >> still better than what we have now, but it seems grotty. > > > I'd be perfectly happy to hear a reasonable alternative. > > 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. > > One point here is that you'd have to restrict the rearrangements so that > the relative sort order of existing values never changes, else you break > (for example) indexes on columns of that type. Sorry to be commenting late, but don't most people want to add to the end or beginning of the enum list, rather than in the middle, and can't we support that already? -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- 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 23 Jun 2010 19:30
Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: > >> Well, we don't need the enum value to map into the entire oid range. >> Can't we just add one to the top-most value and see if there is a >> conflict? >> > > If you don't use the OID counter to generate the new value, you're going > to have problems with race conditions. There's also that small chance > that there is no free value before 2^32. > > The bottom line here is not wanting a feature that "usually" works but > fails once in awhile on the basis of conditions the user can't control. > > Yeah, what I'm now hoping to be able to do, following good suggestions from Tom, is to provide a way to get virtually no degradation in bulk comparison performance in the common case where any additions have been made at the end of the list with no oid wraparound, and acceptable performance otherwise, but provide for an ability to add new values at arbitrary places in the ordering, with no limit. If we can do that why would we want less? 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 |