We do want standard-compliant behavior, and standard-compliance a strength of
PostgreSQL, and as mentioned we already do have a way (DEFERRABLE INITIALLY
DEFERRED) if this is the user's intent.
The consequences of non-compliance is much more insidious than it at first
appears. At stake here is whether PostgreSQL supports non-deferrable
constraints at all. The purpose of having non-deferrable IMMEDIATE
constraints in the standard is to make query optimizations possible.
Also, as far as I can tell, we do not document the specific name that we
generate for constraint triggers; therefore, any application that depends on
undocumented naming conventions is skating on precariously thin ice, in
addition to writing non-portable code.
The equivalent logic was implemented on Oracle and MySQL. Both of those
systems implement IMMEDIATE mode constraints consistently with the standard,
and produce a different result than PostgreSQL.
best regards,
/Jim F
-----
Jim Finnerty, AWS, Amazon Aurora PostgreSQL
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-bugs-f2117394.html
