| From: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
|---|---|
| To: | Vik Fearing <vik(at)postgresfriends(dot)org> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Subject: | Re: Logical Implication |
| Date: | 2026-09-29 20:23:44 |
| Message-ID: | CAN4CZFPUmkNyYP=MJbCE3OC21-De9AYhJXOD_wd8Q06E6xBzqQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello!
One test nitpick:
+SELECT istrue IMPLIES isnul IS NULL FROM booltbl4;
istrue IMPLIES (isnul IS NULL) and (istrue IMPLIES isnul) IS NULL are
both true. isfalse wouldn't have the same issue.
%left INTERSECT
+%right IMPLIES
%left OR
And +1 for using %nonassoc instead
That way "a IMPLIES b IMPLIES c" would be a syntax error, leaving open
the later possibility of making it right associative. The other way of
going with right, and then restricting it later doesn't seem that
clean, even with documenting it, as right associative use can appear
as text in plpgsql bodies and similar.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Kane | 2026-09-29 20:28:21 | Re: Fix conversion warnings in headers |
| Previous Message | Alexander Lakhin | 2026-09-29 20:00:00 | Re: REPACK (CONCURRENTLY) can crash a logical decoding session |