Re: Adding a distinct "pattern" type to resolve the "~" commutator stalemate

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Adding a distinct "pattern" type to resolve the "~" commutator stalemate
Date: 2011-06-19 18:56:43
Message-ID: BANLkTi=EUCyLVW1FfQV996+wJBFx94cmqg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> Amidst the discussion, Alvaro suggested that we resolve the issue
> by adding a distinct type for patterns as opposed to text. That'd
> allow us to make "~" it's own commutator by defining both
>  text ~ pattern
> and
>  pattern ~ text.

That's kind of a neat idea. There might be an efficiency benefit to
having a regex type that is precompiled by the input function.

> There's also the question of how we deal with "~~" (the operator
> behind LIKE). We could either re-use the type "pattern" for that,
> meaning that values of type "pattern" would represent any kind of
> text pattern, not necessarily a regular expression. Alternatively,
> we could represent LIKE pattern by a type distinct from "pattern",
> say "likepattern". Finally, we could handle LIKE like we handle
> SIMILAR TO, i.e. define a function that transforms a LIKE pattern
> into a regular expression, and deprecate the "~~" operator and friends.
>
> The last option looks appealing from a code complexity point of view,
> but might severely harm performance of LIKE and ILIKE comparisons.

I don't believe it would be a very good idea to try to shoehorn
multiple kinds of patterns into a single pattern type.

I do think this may be the long route to solving this problem, though.
Is it really this hard to agree on a commutator name? I mean, I'm
not in love with anything that's been suggested so far, but I could
live with any of them. An unintuitive operator name for
matches-with-the-arguments-reversed is not going to be the worst wart
we have, by a long shot...

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Cédric Villemain 2011-06-19 19:13:49 Re: the big picture for index-only scans
Previous Message Robert Haas 2011-06-19 18:52:12 Re: [WIP] cache estimates, cache access cost