Message-ID: <7464b4ea-1f3b-b4db-f97c-38957dbee87a@postgresfriends.org>
Date: Sat, 26 Nov 2022 01:13:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: BUG #17696: Creation of deferrable initially deferred constraint
 breaks before transaction commit
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
 Roman Garcia <yzerno@gmail.com>, pgsql-bugs@lists.postgresql.org
References: <20221124222356.qolurdwwcnxkbjt2@alvherre.pgsql>
 <3976549.1669344944@sss.pgh.pa.us>
From: Vik Fearing <vik@postgresfriends.org>
In-Reply-To: <3976549.1669344944@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/7464b4ea-1f3b-b4db-f97c-38957dbee87a%40postgresfriends.org>
Precedence: bulk

On 11/25/22 03:55, Tom Lane wrote:
> On the whole I share David's guess that the cost/benefit ratio of
> making this happen is unattractive.  I might feel impelled to do
> it anyway if somebody could show that the SQL spec requires it ...
> but I bet you'll search for that in vain, because I doubt that the
> SQL spec requires transactional DDL at all.  (There are too many
> influential implementations that would have a problem with that.)

The spec does require transactional DDL (SQL:2016 4.41.1 General 
description of SQL-transactions) but does not allow mixing of DDL and 
DML in the same transaction.  What happens when you do that is 
implementation-defined.

So in this case it would not really matter when the new constraint is 
verified because the user would have no opportunity to fix the data anyway.
-- 
Vik Fearing