| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | itdev(at)itdevel(dot)internal(dot)net |
| Cc: | pgsql-sql <pgsql-sql(at)postgresql(dot)org> |
| Subject: | Re: functions allowed in CHECK constraints |
| Date: | 2018-02-09 13:58:52 |
| Message-ID: | CAKFQuwY6=rJ0J+b9b4VQ=JkJUTdv95N9bmUE9MZojzdetJM3Ow@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
On Fri, Feb 9, 2018 at 1:37 AM, Achilleas Mantzios <
itdev(at)itdevel(dot)internal(dot)net> wrote:
>
> So, what's the point in forbidding the use of subselects if one can use
> functions? And OTOH if effectively doing so is bad for some reason, why let
> it happen with a function?
Short answer, the system treats the function as a black-box and doesn't
know that you've used it to circumvent its prohibition on subselects. The
prohibition still is in place though. If you use a function you are
expected to ensure you do not violate any of the restrictions yourself.
The reason it is bad is because the query is only run at row insertion time
- and if the external data that the subquery references changes the check
constraint can become invalidated. If that happens at minimum a
dump/restore will fail.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2018-02-09 14:06:31 | Re: functions allowed in CHECK constraints |
| Previous Message | Achilleas Mantzios | 2018-02-09 11:23:10 | Re: functions allowed in CHECK constraints |