Vik Fearing <vik.fearing@2ndquadrant.com> writes:
> On 06/12/2018 15:41, Tom Lane wrote:
>> So what I'm thinking we should do is document that the behavior of a
>> domain CHECK constraint is expected to be immutable, and it's on the
>> user's head to preserve consistency if it isn't. We could recommend
>> that any attempt to change a constraint's behavior be implemented by
>> dropping and re-adding the constraint, which is a case that the system
>> does know what to do with.
>>
>> Actually, the same goes for table CHECK constraints ...
> I got annoyed several years ago that CHECK constraints aren't required
> to be immutable. I don't understand why that's the case but there's a
> regression test specifically for it so I never did anything about it.
Well, there *are* use cases for it. A simple example is
create table ...
event_time timestamptz check (event_time <= now()),
if you want to ensure that no "in the future" event gets inserted.
The real restriction is not so much immutability as that the constraint
must get monotonically weaker, ie it must never reject a row it
previously accepted. But I dunno that we want to go into that in
the documentation. People who need such things can probably figure
it out for themselves.
regards, tom lane
