Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

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 t

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

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 distin

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun20, 2011, at 03:16 , Greg Stark wrote: > On Fri, Jun 17, 2011 at 3:49 PM, Florian Pflug wrote: >>> The regex is always to the right of the operator. >> >> Which is something you have to remember... It's not in any >> way deducible from "foo ~ bar" alone. > > Except that it's always been th

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Fri, Jun 17, 2011 at 3:49 PM, Florian Pflug wrote: >> The regex is always to the right of the operator. > > Which is something you have to remember... It's not in any > way deducible from "foo ~ bar" alone. Except that it's always been this way, going back to perl4 or tcl or their predecessors

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun17, 2011, at 17:46 , Alvaro Herrera wrote: > Excerpts from Florian Pflug's message of vie jun 17 10:49:46 -0400 2011: > Maybe, but the mnemonic rule seems quite a bit easier (to me anyway). > In my head I think of ~ as "matches", so "text matches regex", whereas > "regex matches text" doesn't

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun17, 2011, at 18:00 , Robert Haas wrote: > On Fri, Jun 17, 2011 at 11:46 AM, Alvaro Herrera > wrote: >> I guess this wouldn't be much of a problem if you could use ANY/ALL with >> a function instead of an operator, c.f. map(). > > Yeah. Or really what you want is a lambda-expression, rather

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Fri, Jun 17, 2011 at 05:21:10PM +0200, Florian Pflug wrote: > On Jun17, 2011, at 17:15 , Ross J. Reedstrom wrote: > > On Fri, Jun 17, 2011 at 10:20:04AM -0400, Alvaro Herrera wrote: > >> Excerpts from Florian Pflug's message of vie jun 17 10:03:56 -0400 2011: > >> > >>> How is that worse than t

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Fri, Jun 17, 2011 at 11:46 AM, Alvaro Herrera wrote: > I guess this wouldn't be much of a problem if you could use ANY/ALL with > a function instead of an operator, c.f. map(). Yeah. Or really what you want is a lambda-expression, rather than a predefined function. fold(bool_and, map { val ~

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

Excerpts from Florian Pflug's message of vie jun 17 10:49:46 -0400 2011: > On Jun17, 2011, at 16:20 , Alvaro Herrera wrote: > > Excerpts from Florian Pflug's message of vie jun 17 10:03:56 -0400 2011: > >> So? How does that reduce that risk of somebody writing "pattern ~ text" > >> instead of "text

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun17, 2011, at 17:15 , Ross J. Reedstrom wrote: > On Fri, Jun 17, 2011 at 10:20:04AM -0400, Alvaro Herrera wrote: >> Excerpts from Florian Pflug's message of vie jun 17 10:03:56 -0400 2011: >> >>> How is that worse than the situation with "=~" and "~="? >> >> With =~ it is to the right, with

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Fri, Jun 17, 2011 at 10:20:04AM -0400, Alvaro Herrera wrote: > Excerpts from Florian Pflug's message of vie jun 17 10:03:56 -0400 2011: > > > How is that worse than the situation with "=~" and "~="? > > With =~ it is to the right, with ~= it is to the left. To throw my user opinion into this

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun17, 2011, at 16:20 , Alvaro Herrera wrote: > Excerpts from Florian Pflug's message of vie jun 17 10:03:56 -0400 2011: >> So? How does that reduce that risk of somebody writing "pattern ~ text" >> instead of "text ~ pattern"? Modifying your quote from above >> >> foo ~ 'bar'/* foo

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On 06/17/2011 10:20 AM, Alvaro Herrera wrote: alvherre=# \doS ~ Listado de operadores Esquema | Nombre | Tipo arg izq | Tipo arg der | Tipo resultado | Descripción ++--+--+--

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

Excerpts from Florian Pflug's message of vie jun 17 10:03:56 -0400 2011: > On Jun17, 2011, at 15:36 , Alvaro Herrera wrote: > > Excerpts from Florian Pflug's message of vie jun 17 04:46:32 -0400 2011: > >> On Jun17, 2011, at 03:42 , Alvaro Herrera wrote: > >>> To make matters worse, our delimiters

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun17, 2011, at 15:36 , Alvaro Herrera wrote: > Excerpts from Florian Pflug's message of vie jun 17 04:46:32 -0400 2011: >> On Jun17, 2011, at 03:42 , Alvaro Herrera wrote: >>> To make matters worse, our delimiters for regexes are the same as for >>> strings, the single quote. So you get >>> >

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

Excerpts from Florian Pflug's message of vie jun 17 04:46:32 -0400 2011: > On Jun17, 2011, at 03:42 , Alvaro Herrera wrote: > > To make matters worse, our delimiters for regexes are the same as for > > strings, the single quote. So you get > > > > foo =~ 'bar'/* foo is the text column, bar is

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun17, 2011, at 03:42 , Alvaro Herrera wrote: > To make matters worse, our delimiters for regexes are the same as for > strings, the single quote. So you get > > foo =~ 'bar' /* foo is the text column, bar is the regex */ > 'bar' =~ foo /* no complaint but it's wrong */ > > 'bar' ~= foo /*

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

Excerpts from Tom Lane's message of jue jun 16 17:33:17 -0400 2011: > Peter Eisentraut writes: > > I don't really agree that visual correlation needs to trump everything. > > If say > > foo =~ bar > > and > > foo ~= bar > > were to produce completely different results, this would introduce

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun16, 2011, at 21:49 , Tom Lane wrote: > All three of these are massive overkill. What we need is a general > policy that providing commutators is a good idea. We do not need to try > to make it 100.00% with an enforcement mechanism. What parts of (1) do you think are overkill exactly, then?

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

Peter Eisentraut writes: > I don't really agree that visual correlation needs to trump everything. > If say > foo =~ bar > and > foo ~= bar > were to produce completely different results, this would introduce bugs > all over the place. Huh? That's about like arguing that standard mathema

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On tor, 2011-06-16 at 00:50 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > On tis, 2011-06-14 at 15:38 +0200, Florian Pflug wrote: > >> BTW, there's actually precedent for a commutator of "~", namely > >> "@". Some of the geometric types (polygon, box, circle, point, > >> path) use "~" as a

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

Florian Pflug writes: > Well, I think there are basically three choices here, kludge or no > kludge. > (1) We either decree once and for all that binary operations ought to > have commutators, modify CREATE TYPE to issue a warning if you > create one without, add the missing ones, and add a check

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Thu, Jun 16, 2011 at 2:22 PM, Florian Pflug wrote: > On Jun16, 2011, at 19:54 , Robert Haas wrote: >> On Thu, Jun 16, 2011 at 12:50 AM, Tom Lane wrote: >>> We deprecated those names for the geometric operators largely because >>> there wasn't any visual correlation between the commutator pairs

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun16, 2011, at 19:54 , Robert Haas wrote: > On Thu, Jun 16, 2011 at 12:50 AM, Tom Lane wrote: >> We deprecated those names for the geometric operators largely because >> there wasn't any visual correlation between the commutator pairs. >> I can't see introducing the same pairing for regex oper

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

Robert Haas writes: > I'm having trouble avoiding the conclusion that we're trying to shove > a round peg into a square hole. The idea that we have to have a > commutator for every operator just because we don't handle left and > right symmetrically sits poorly with me. I can't really argue with

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Thu, Jun 16, 2011 at 12:50 AM, Tom Lane wrote: > We deprecated those names for the geometric operators largely because > there wasn't any visual correlation between the commutator pairs. > I can't see introducing the same pairing for regex operators if we > already decided the geometric case wa

Re: [WIP] Support for "ANY/ALL(array) op scalar" (Was: Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY)

On Jun16, 2011, at 04:19 , Tom Lane wrote: > Florian Pflug writes: >> Comments are extremely welcome, especially ones regarding >> the overall approach taken in this patch. If people consider >> that to be acceptable, I'd try to add the missing features >> and add documentation. > > Quite honestl

Re: [WIP] Support for "ANY/ALL(array) op scalar" (Was: Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY)

Peter Eisentraut writes: > On ons, 2011-06-15 at 22:19 -0400, Tom Lane wrote: >> (FWIW, I've come around to liking the idea of using =~ and the obvious >> variants of that for regex operators, mainly because of the Perl >> precedent.) > Maybe I'm not completely up to date on this, but I observe t

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

Peter Eisentraut writes: > On tis, 2011-06-14 at 15:38 +0200, Florian Pflug wrote: >> BTW, there's actually precedent for a commutator of "~", namely >> "@". Some of the geometric types (polygon, box, circle, point, >> path) use "~" as a commutator for "@" (which stands for "contains"). > I woul

Re: [WIP] Support for "ANY/ALL(array) op scalar" (Was: Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY)

On ons, 2011-06-15 at 22:19 -0400, Tom Lane wrote: > (FWIW, I've come around to liking the idea of using =~ and the obvious > variants of that for regex operators, mainly because of the Perl > precedent.) Maybe I'm not completely up to date on this, but I observe that Perl itself doesn't appear to

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On tis, 2011-06-14 at 15:38 +0200, Florian Pflug wrote: > BTW, there's actually precedent for a commutator of "~", namely > "@". Some of the geometric types (polygon, box, circle, point, > path) use "~" as a commutator for "@" (which stands for "contains"). I wouldn't have a problem with naming t

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On mån, 2011-06-13 at 10:19 -0400, Andrew Dunstan wrote: > On 06/13/2011 10:07 AM, Robert Haas wrote: > > Some languages use =~ and some use just ~... I was just > > wondering if anyone thought the commutator of =~ was ~=... > > My feeling is it's a bit dangerous. It's too easy to fat-finger the

Re: [WIP] Support for "ANY/ALL(array) op scalar" (Was: Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY)

Florian Pflug writes: > Comments are extremely welcome, especially ones regarding > the overall approach taken in this patch. If people consider > that to be acceptable, I'd try to add the missing features > and add documentation. Quite honestly, I don't like this one bit and would rather you not

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun14, 2011, at 14:29 , Robert Haas wrote: > On Tue, Jun 14, 2011 at 6:10 AM, Florian Pflug wrote: >> On Jun13, 2011, at 05:44 , Tom Lane wrote: >>> Robert Haas writes: On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug wrote: > (B) There should be a way to use ANY()/ALL() with the >

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Tue, Jun 14, 2011 at 6:10 AM, Florian Pflug wrote: > On Jun13, 2011, at 05:44 , Tom Lane wrote: >> Robert Haas writes: >>> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug wrote: (B) There should be a way to use ANY()/ALL() with the array elements becoming the left arguments of the op

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun13, 2011, at 05:44 , Tom Lane wrote: > Robert Haas writes: >> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug 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

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun13, 2011, at 16:19 , Andrew Dunstan wrote: > On 06/13/2011 10:07 AM, Robert Haas wrote: >> Some languages use =~ and some use just ~... I was just >> wondering if anyone thought the commutator of =~ was ~=... > > My feeling is it's a bit dangerous. It's too easy to fat-finger the reverse >

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Mon, Jun 13, 2011 at 09:01:45AM +0200, Florian Pflug wrote: > Hm, that's less bulky but more kludgy, I'd say. But wait a minute... > > If ANY and ALL are reserved anyway, should it be possible to > make "(ANY(..) )" and "(ALL(...) )" > work grammar-wise? (Note the enclosing parens) This woul

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On 06/13/2011 10:07 AM, Robert Haas wrote: Some languages use =~ and some use just ~... I was just wondering if anyone thought the commutator of =~ was ~=... My feeling is it's a bit dangerous. It's too easy to fat-finger the reverse op, and get something quite unintended. cheers andrew (

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Mon, Jun 13, 2011 at 3:01 AM, Florian Pflug wrote: > On Jun13, 2011, at 05:12 , Robert Haas wrote: >> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug 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 m

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

Robert Haas writes: > On Sun, Jun 12, 2011 at 11:44 PM, Tom Lane wrote: >> There are syntactic reasons not to do that. It'd be a lot easier just >> to provide a commutator operator for ~. > Details? Well, for one, it becomes unobvious what A op ANY (B) op C means. This has come up b

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun13, 2011, at 05:44 , Tom Lane wrote: > Robert Haas writes: >> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug wrote: >>> (C) Why do we forbid sub-queries in CHECK constraints? > >> Dunno. Maybe it's just an implementation restriction? > > (1) We don't want to invoke the planner in the pla

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Sun, Jun 12, 2011 at 6:46 AM, Florian Pflug wrote: > (B) There should be a way to use ANY()/ALL() with the > array elements becoming the left arguments of the operator. FWIW, in case people were unaware, this is getting close to Perl 6 junctions/superpositions. See:

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun13, 2011, at 05:12 , Robert Haas wrote: > On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug 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 >> highlight

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Sun, Jun 12, 2011 at 11:44 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug 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

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

Robert Haas writes: > On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug 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;

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug 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 nam

[HACKERS] Boolean operators without commutators vs. ALL/ANY

Hi I've recently wanted to define a check constraint on an array column that verifies that all array entries match some regular expression. Unfortunately, t The most natural way of expressing such a check would be CHECK ('' ~ ANY(field)), but that doesn't work, because "~" expects the *value* t