Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: > On 09/22/2017 11:19 PM, Tom Lane wrote: >> Yeah, I was considering the same thing over dinner, though I'd phrase >> it oppositely: keep a list of enum type OIDs created in the current >> transaction, so that we could whitelist them. This could maybe become >> a problem if someone created a zillion enums in one xact, though.
> I see what you're saying, but my idea was slightly different. We would > only add to the hashtable I had in mind at the bottom AddEnumLabel(). > Any other value, whether added in the current transaction or not, should > be safe, AIUI. Oh, I see: a list of enum values we need to blacklist, not whitelist. Yes, that's a significantly better idea than mine, because in common use-cases that would be empty or have a very small number of entries. In particular that fixes the "pg_restore -1" scenario, because no matter how many enums you're restoring, pg_dump doesn't use ALTER TYPE ADD VALUE. (Well, it does in --binary-upgrade mode, but those scripts are run in transaction-per-statement mode so it's fine.) > Maybe we should also keep a cache of whitelisted enums > created in the current transaction. What for? Wouldn't be any faster to search, in fact likely slower because it could get large in common use-cases. >> The immediate question is do we care to design/implement such a thing >> post-RC1. I'd have to vote "no". I think the most prudent thing to >> do is revert 15bc038f9 and then have another go at it during the v11 >> cycle. > Sadly I agree. We've made decisions like this in the past, and I have > generally been supportive of them. I think this is the first time I have > been on the receiving end of one so late in the process :-( Unless you want to try writing a patch for this in the next day or two, I think we have to do that. But now that I see the plan clearly, maybe we could get away with a post-RC1 fix. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers