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 BANLkTimrDL-_-WD2WGnV4OE9pVdh7YjfLA@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 Mon, Jun 13, 2011 at 3:01 AM, Florian Pflug <fgp@phlo.org> wrote:
> On Jun13, 2011, at 05:12 , Robert Haas wrote:
>> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug <fgp@phlo.org> wrote:
>>> So I the end, I had to wrap the sub-query in a SQL-language
>>> function and use that in the check constraint. While this
>>> solved my immediate problem, the necessity of doing that
>>> highlights a few problems
>>>
>>> (A) "~" is an extremely bad name for the regexp-matching
>>> operators, since it's visual form is symmetric but it's
>>> behaviour isn't. This doesn't only make its usage very
>>> error-prone, it also makes it very hard to come up with
>>> sensible name for an commutator of "~". I suggest that we
>>> add "=~" as an alias for "~", "~=" as an commutator
>>> for "=~", and deprecate "~". The same holds for "~~".
>>
>> Does any other database or programming language implement it this way?
>
> Ruby has "=~", which returns the position of the regexp's first
> match, or nil if there is none.
>
> $ ruby -e "puts 'hello' =~ /l+/"
> 2
> $ ruby -e "puts 'hello' =~ /x+/"
> nil

Sure.  Some languages use =~ and some use just ~... I was just
wondering if anyone thought the commutator of =~ was ~=...

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


pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: pgbench cpu overhead (was Re: lazy vxid locks, v1)
Next
From: Andrew Dunstan
Date:
Subject: Re: wrong message on REASSIGN OWNED