From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Matthew Morrissette Vance <yinzara(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Commutation of array SOME/ANY and ALL operators |
Date: | 2024-10-24 01:57:14 |
Message-ID: | 2350174.1729735034@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Matthew Morrissette Vance <yinzara(at)gmail(dot)com> writes:
> If instead, PostgreSQL could support the commutation of the `SOME/ANY` and
> `ALL` operators so that the `ANY(array)` could be on both sides of the
> provided operator, it would allow for this kind of searching natively.
> Firstly, would a PR that enhanced PostgreSQL in this manner be accepted?
My gut feeling is you'll run into insurmountable grammar-ambiguity
problems. I might be wrong, but I have an idea that this has
already been tried and failed on that point.
Inventing commutator operators for LIKE etc could be a path of
much less resistance (unless the operator names get bikeshedded
to death). Are there really that many that people need?
A quick query of pg_operator suggests that the LIKE/regex family
is the bulk of the problem for real-world cases.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2024-10-24 02:01:47 | Re: Inconsistent use of relpages = -1 |
Previous Message | Michel Pelletier | 2024-10-24 01:39:03 | Re: Using Expanded Objects other than Arrays from plpgsql |