On Mon, Apr 13, 2020 at 04:22:26PM -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> I'd much rather see this throw an assertion than the current
>> behaviour. But I'm wondering if there's a chance we can throw an error
>> in non-assert builds without adding too much complexity to the error
>> paths. Could we perhaps throw the error a bit later during the commit
>> processing?
>
> Any error post-commit is a semantic disaster.
Yes, I can immediately think of two problems in the very recent
history where this has bitten.
> I guess that an assertion wouldn't be so awful, if people would rather
> do it like that in debug builds.
WARNING is useful mainly for tests where the output is checked, like
the main regression test suite. Now that TAP scenarios get more and
more complex, +1 on the addition of an assertion for a hard failure.
I don't think either that's worth controlling with a developer GUC.
--
Michael
