| From: | Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Mutability of domain CHECK constraints |
| Date: | 2018-12-29 23:03:04 |
| Message-ID: | 1cef8397-5ff4-1692-e763-1eda1fff958a@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-12-29 23:14:58 | Re: Mutability of domain CHECK constraints |
| Previous Message | Tom Lane | 2018-12-29 22:33:38 | pgsql: Use a separate random seed for SQL random()/setseed() functions. |