Re: Boolean operators without commutators vs. ALL/ANY

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Boolean operators without commutators vs. ALL/ANY
Date: 2011-06-20 17:32:04
Message-ID: FE03FF95-FD44-4DAB-8F42-11FF5FE47DD3@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jun20, 2011, at 19:22 , Alvaro Herrera wrote:
> Excerpts from Florian Pflug's message of lun jun 20 06:55:42 -0400 2011:
>> The latter (i.e. regexp literals enclosed by /../) probably isn't
>> desirably for postgres, but the former definitely is (i.e. distinguishing
>> regexp's and text in the type system). Please see the thread
>> "Adding a distinct pattern type to resolve the ~ commutator stalemate"
>> for the details of the proposal.
>
> 'your text' ~ regexp 'your.*foo'
> column ~ regexp 'your.*foo'
>
> So you could do
>
> regexp 'foo.*bar' ~ 'your text'
>
> and it's immediately clear what's up.
>
> The question is what to do wrt implicit casting of text to regexp.
> If we don't, there's a backwards compatibility hit.

No, we certainly musn't allow text to be implicitly converted to
regexp, for otherwise e.g. "varchar ~ varchar" becomes ambiguous.

I posted a primitive prototype for a pattern type on said thread,
which seems to do everything we require without causing compatibility
problems.

best regards,
Florian Pflug

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2011-06-20 17:33:19 Re: Range Types and extensions
Previous Message Alvaro Herrera 2011-06-20 17:27:23 Re: Patch - Debug builds without optimization