Alvaro Herrera <alvhe...@commandprompt.com> writes:
> Excerpts from Tom Lane's message of mar oct 25 14:57:43 -0300 2011:
>> ... Or maybe we could
>> back-patch a change in creation order and rely on that usually working.
>> Given the lack of prior complaints that might be good enough.
> The latter looks reasonable ... particularly if the symptoms of a
> botched order would be immediately visible -- the user could just drop
> and reload the constraints to fix the order in the very unlikely case
> that they are reversed.
Well, the symptoms would probably be just like in the bug report: you'd
get unexpected failures from double updates of a self-referential row in
a single transaction. That's a sufficiently weird corner case that most
people probably wouldn't exercise it right away. But given that this
problem has been there from day one and nobody noticed before, I'm not
too concerned about the intersection of people who have an issue and
people who are unlucky enough to get an end-of-decade trigger OID.
I think 100% solution in HEAD and 99.99% solution in back branches
should be good enough.
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
