Re: Boolean operators without commutators vs. ALL/ANY - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Boolean operators without commutators vs. ALL/ANY
Date
Msg-id BANLkTi=r4xFkdj_kZFhaAAeqW7d744FdOA@mail.gmail.com
Whole thread Raw
In response to Re: Boolean operators without commutators vs. ALL/ANY  (Florian Pflug <fgp@phlo.org>)
Responses Re: Boolean operators without commutators vs. ALL/ANY
List pgsql-hackers
On Tue, Jun 14, 2011 at 6:10 AM, Florian Pflug <fgp@phlo.org> wrote:
> On Jun13, 2011, at 05:44 , Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug <fgp@phlo.org> wrote:
>>>> (B) There should be a way to use ANY()/ALL() with the
>>>> array elements becoming the left arguments of the operator.
>>
>>> It seems to me that if we provided some way of handling this, your
>>> first proposal would be moot; and I have to say I like the idea of
>>> allowing this a lot more than tinkering with the operator names.
>>
>> There are syntactic reasons not to do that.  It'd be a lot easier just
>> to provide a commutator operator for ~.
>
> My suggestion would be the add a commutator for "~" as a short-term
> solution (preferably in 9.1).

I don't think we want to bump catversion again before release if we
can avoid it.  And I don't see this as being a terribly urgent problem
- it's not like this is a new regression, and I can't remember hearing
any complaints about it prior to two days ago.

> Since "~" doesn't inspire any obvious names for a possible commutator,
> I suggest adding "=~" and "~=".
>
> Is there any support for that proposal?

I'm OK with adding a commutator but I guess I don't see the point of
adding a synonym for ~ along the way.  The existing use of ~ is
consistent with, for example, awk, so it's not like we've dreamed up
something utterly crazy that we now need to fix.  I'd suggest we just
come up with some arbitrary variant, like ~~ or <~ or #~ or
!#!%@~bikeshed++!.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: PATCH: CreateComments: use explicit indexing for ``values''
Next
From: Franklin Haut
Date:
Subject: Re: 9.1 beta1 error