| From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Roman Garcia <yzerno(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17696: Creation of deferrable initially deferred constraint breaks before transaction commit |
| Date: | 2022-11-26 00:13:29 |
| Message-ID: | 7464b4ea-1f3b-b4db-f97c-38957dbee87a@postgresfriends.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jaime Casanova | 2022-11-26 00:44:46 | Re: BUG #17696: Creation of deferrable initially deferred constraint breaks before transaction commit |
| Previous Message | Vik Fearing | 2022-11-25 23:19:23 | Re: Inaccurate documentation about identifiers |