Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
> On 09/24/2017 04:37 PM, Tom Lane wrote:
>> What we still need to debate is whether to remove the heuristic
>> type-is-from-same-transaction test, making the user-visible behavior
>> simply "you must commit an ALTER TYPE ADD VALUE before you can use the
>> new value". I'm kind of inclined to do so; the fuzzy (and inadequately
>> documented) behavior we'll have if we keep it doesn't seem very nice to
>> me.
> I'd rather not. The failure cases are going to be vanishingly small, I
> suspect, and we've already discussed how we might improve that test. If
> you want to put some weasel words in the docs that might be ok.
I'm unconvinced. We get enough complaints about heuristic behaviors
we have elsewhere. Also, if we ship it like this, we're going to
have backward compatibility concerns if we try to change the behavior
later. Now admittedly, the next step forward might well be an exact
solution which would necessarily take every case the heuristic allows
--- but I don't want to box us into having to support exactly the
cases the heuristic would allow. And I don't want to have to
document which those are, either.
Basically, I don't think anyone's shown an important use case that
wouldn't be covered by "committed or not blacklisted". That fixes
the original complaint that you couldn't do ALTER ADD VALUE in a
transaction block at all, and with or without the heuristic test,
you can't use the added value without committing. The case not
covered is where an enum type is built with multiple commands in a
single transaction --- which might be of value, but since it doesn't
work for every such case, we don't know if the heuristic is really
going to provide useful value-add or not.
So I think we should just stop with the blacklist test for v10,
and then see if we still get complaints (and exactly what they're
about) so that we can judge how much more work the problem deserves.
It's still ahead of where we were in previous releases, and ahead of
where we'd be if we end up reverting the patch altogether.
Or in short: having been burned by this heuristic already, I want
it out of there.
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
