Re: WIP: extensible enums
Dean Rasheed <dean.a.rasheed@gmail.com>
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2010-10-24T12:01:26Z
Lists: pgsql-hackers
On 24 October 2010 05:26, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Well, the easy way to read a consistent view of the world is to load the > cache using an MVCC snapshot instead of SnapshotNow. The current code > structure isn't amenable to that because it's relying on a syscache to > fetch the data for it, but that seems pretty inefficient anyway. I'm > thinking of changing it around so that the enum cache gets loaded with > a regular systable_beginscan() scan, and then we could load with an > MVCC snapshot. > > I'm kind of inclined to go to the float-based representation anyway, > though, just because not having to update other rows to do an insert > seems like a good thing. But we could combine that with an MVCC > snapshot on the read side, which would make renumbering safe, which > would mean that we could auto-renumber when we ran out of code space > and not otherwise. Is that getting too complicated? > As an alternative, how about storing the sort order as an array of OIDs, in a single row in pg_type, or a new table, rather than across multiple rows in pg_enum. Code that read it would be guaranteed a consistent view of the data, and at worst, it might be missing recently added elements, which the comparison code can already deal with by re-reading the array. Regards, Dean > regards, tom lane >