Re: Adding a distinct "pattern" type to resolve the "~" commutator stalemate - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: Adding a distinct "pattern" type to resolve the "~" commutator stalemate
Date
Msg-id 0134E293-FF0E-4A4B-B153-203D077F5B57@kineticode.com
Whole thread Raw
In response to Re: Adding a distinct "pattern" type to resolve the "~" commutator stalemate  (Florian Pflug <fgp@phlo.org>)
Responses Re: Adding a distinct "pattern" type to resolve the "~" commutator stalemate
List pgsql-hackers
On Jun 19, 2011, at 4:56 PM, Florian Pflug wrote:

> Hm, it seems we either all have different idea about how such
> a pattern type would be be defined, or have grown so accustomed to
> pg's type system that we've forgotten how powerful it really
> is ;-) (For me, the latter is surely true...).
>
> I've now created a primitive prototype that uses a composite
> type for "pattern". That changes the input syntax for patterns
> (you need to enclose them in brackets), but should model all
> the implicit and explicit casting rules and operator selection
> correctly. It also uses "~~~" in place of "~", for obvious
> reasons and again without changing the casting and overloading
> rules.

Ew.

> The prototype defines
>  text ~~~ text
>  text ~~~ pattern
>  pattern ~~~ text
> and can be found at end of this mail.
>
> With that prototype, *all* the cases (even unknown ~~~ unknown)
> work as today, i.e. all of the statements below return true

Florian++ Very nice, thanks!

I don't suppose there's a special quoting to be had for patterns? Perhaps one of these (modulo SQL parsing issues);
   /pattern/   {pattern}   qr/pattern/   qr'pattern'   R/pattern/   R'pattern'

Mike bikeshed is scarlet,

David



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Range Types and extensions
Next
From: Florian Pflug
Date:
Subject: Re: Adding a distinct "pattern" type to resolve the "~" commutator stalemate