On 2012-12-01 12:01:17 -0500, Andrew Dunstan wrote: > > On 12/01/2012 11:38 AM, Andres Freund wrote: > >On 2012-12-01 17:36:20 +0100, Andres Freund wrote: > >>On 2012-12-01 17:03:03 +0100, Andres Freund wrote: > >>>Could we possibly allow adding enum values to a type which was just > >>>created in > >>>this transaction? That shouldn't be too hard. At least easier than > >>>providing > >>>the capability to pre-assign the next N oids... > >>The attached patch does just that. Its *not* ready yet though, as it > >>will be apparent for everyone who reads it ;) > >> > >>To really make that work in a reliable manner we would probably need > >>an rd_createSubid for typcache entries instead of testing xmin as I have > >>done here? > > > Does this actually get you over the problem identified in the comment?: > > * We disallow this in transaction blocks, because we can't cope > * with enum OID values getting into indexes and then having their > * defining pg_enum entries go away.
I don't see why not at least. No index that can contain values from the enum will survive a transaction abort or can be seen from the outside before it committed. So I don't see a problem. What made you concerned? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
