Re: set constraints behavior

Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> writes:
> Second question: SQL92 also specifies this for SET CONSTRAINTS --

> 1) If an SQL-transaction is currently active, then let TXN be the
> currently active SQL-transaction. Otherwise, let TXN be the next
> SQL-transaction for the SQL-agent.

> (section 14.2, page 400)

> In PostgreSQL, SET CONSTRAINTS only affects the current
> transaction. Is it possible to make this more compliant?

Well, what definition do you propose? I don't think there's currently
any usefulness to SET CONSTRAINTS outside a transaction block, so we
could change its behavior without breaking anything.

Given that we don't define transaction boundaries the same way SQL92
does (BEGIN isn't SQL), I'm not sure that exact spec compliance is
the right consideration here anyway.

Note however that there are proposals floating around to allow a more
spec-compliant transaction behavior --- eg, a SET variable to cause an
"implicit BEGIN" on any SQL command outside a transaction block.
It'd be a good idea to keep that in mind while thinking about how SET
CONSTRAINTS ought to behave.

regards, tom lane