| From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
|---|---|
| To: | Thom Brown <thom(at)linux(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Logical Implication |
| Date: | 2026-09-11 16:06:50 |
| Message-ID: | 43d5a3f4-30b9-4fa5-9f8f-97aa2dd7cf7c@postgresfriends.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Thom,
Thanks for taking a look at it.
On 11/09/2026 16:41, Thom Brown wrote:
> What behaviour should be expected for the following cases:
>
> a IMPLIES b IMPLIES c
a IMPLIES (b IMPLIES c), it is right associative. I put this exact case
in the documentation.
It deparses to (NOT a) OR (NOT b) OR c.
> CHECK (a IMPLIES b) -- where b is NULL
> -- And what does that deparse to?
This is in the documentation as well, it deparses to NOT a OR NULL
which is either TRUE or UNKNOWN depending on what a is. In both cases
the CHECK passes.
> a IMPLIES (100 / b > 10)
This is an error because the operator only applies to booleans.
--
Vik Fearing
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vik Fearing | 2026-09-11 16:12:51 | Re: Logical Implication |
| Previous Message | Fabrizio Mello | 2026-09-11 16:04:12 | Re: Fix failing assert in deferred constraint trigger |