On Mon, Oct 2, 2023 at 10:25 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > But here we have a > feature whose only possible use is with constraints that *aren't* > immutable; else we might as well just check them immediately.
I'm a little bit confused by this whole discussion because surely this statement is just completely false. The example in the original post demonstrates that clearly. The use case for a deferred check constraint is exactly the same as the use case for a deferred foreign key constraint or a deferred uniqueness constraint, which is that you might have a constraint that will be temporarily false while the transaction is in progress, but true by the time the transaction actually commits, and you might like the transaction to succeed instead of failing in such a case. You seem to be imagining that the constraint itself might be returning mutable answers on the same inputs, but that's not what this is about at all. I'm not here - at least, not right now - to take a position on whether the patch itself is any good. -- Robert Haas EDB: http://www.enterprisedb.com
