On tor, 2011-06-16 at 00:50 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> 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 wouldn't have a problem with naming the reverse operator "@".
>
> 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 was a bad idea.
I actually reported the exact issue that Florian reported a while ago
and we had this same sort of discussion. I think I'm running with a
custom operator named ~~~ somewhere in production. So yay for adding a
commutator in any case.
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. Most programming languages would get away with this
kind of issue because the pattern has a different data type than the
string to be matched against, so mistakes will be caught.
Looking at the list of geometric operators, I can't help but feel that
the silliness of operator naming is reaching its limits. We can
probably come up with a few more for this particular problem, but long
term we might want to think of other solutions, such as attaching the
optimization information to functions instead, and/or inventing an infix
function call syntax like in Haskell.
