extensible enum types
in [PgSql]
|
From: Tom Lane on 18 Jun 2010 12:45 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. 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 12:56 David E. Wheeler wrote: > What's the likelihood of a failure? Constructing a failure case would be simple. In practice, I suspect it would be very low. > And would the position of the new label (represented by its internal number) be predictive? IOW, would updating the same varenumtype in two databases (or on two servers) yield the same underlying positional value? > > > The algorithm I outlined is deterministic, so the same sequence of operations on the type would yield the same set of values on the low-order 16 bits. But that doesn't mean they would have the same high order 16 bits. That would depend on the history of the system. But more importantly, why do you care? the stored value is an implementation artefact that should be totally invisible to users. There would be no guarantee of the same underlying values on dump/reload either, just as there is not now for enums. 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 18 Jun 2010 12:59 David E. Wheeler wrote: > On Jun 18, 2010, at 9:34 AM, Andrew Dunstan wrote: > > >> I'd be perfectly happy to hear a reasonable alternative. Assuming we use some integer representation, given two labels represented by n and n+1, we can't add a label between them without rewriting the tables that use the type, whether it's my representation scheme or some other. Maybe we could have a FORCE option which would rewrite if necessary. >> > > People would likely always use it. > > Why not use a decimal number? > > > You are just bumping up the storage cost. Part of the attraction of enums is their efficiency. 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 18 Jun 2010 13:17 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. > > > Hmm. Yes, that could work. The assumption in my proposal was that existing values would not be reordered anyway. But I'm not happy about giving up cheap comparison. And how would it be per data-type? That part isn't clear to me. Would we mark a given enum type as having its oids in order? It would also be sensible to quantify how much more expensive comparisons would become. If the sort order data were kept in the syscache the extra cost might get very small. What I actually like most about this suggestion is that we would be able to apply it cleanly to existing enum types without inventing anything much new. cheers cheers -- 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 18 Jun 2010 13:18
On Fri, Jun 18, 2010 at 12:59 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: > You are just bumping up the storage cost. Part of the attraction of enums is > their efficiency. What's efficient about them? Aren't we using 4 bytes to store a value that will nearly always fit in 2, if not 1? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |