On 09/22/2017 11:19 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 09/22/2017 05:46 PM, Tom Lane wrote: >>> I'm not sure if that qualifies as a stop-ship problem, but it ain't >>> good, for sure. We need to look at whether we should revert 15bc038f9 >>> or somehow revise its rules. >> I wonder if we wouldn't be better >> doing this more directly, keeping a per-transaction hash of unsafe enum >> values (which will almost always be empty). It might even speed up the >> check. > 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. Maybe we should also keep a cache of whitelisted enums created in the current transaction. I'm not to worried about people creating a zillion enums (or enum labels being added for the solution I had in mind). Even a hash of a million Oids will only consume a few megabytes, won't it? > > 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 :-( cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, 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