| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Patrick B <patrickbakerbr(at)gmail(dot)com> |
| Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: PG 9.1 - FK + Check constraint |
| Date: | 2017-07-19 02:30:15 |
| Message-ID: | CAKFQuwanmBOH27hc3KKo7LUDWXwjSumYX2+5EFAOZdnVofa_Qg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Jul 18, 2017 at 6:56 PM, Patrick B <patrickbakerbr(at)gmail(dot)com> wrote:
> Another solution would be to create an IMMUTABLE functiondoing the check
> and use that in a CHECK constraint [1].
>
Why do you need an FK constraint? Why can you not use a data modification
trigger?
Placing the subquery within a mis-defined immutable function so PostgreSQL
is oblivious to it doesn't do anything to overcome the fact that the system
is not designed to have check constraints with subqueries. You are likely
to get burned - commonly during backup restoration but there is no
guarantees as to why might happen.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | armand pirvu | 2017-07-19 03:05:24 | hash join performance question |
| Previous Message | Patrick B | 2017-07-19 01:56:41 | PG 9.1 - FK + Check constraint |