Re: patch adding new regexp functions - Mailing list pgsql-patches

From Tom Lane
Subject Re: patch adding new regexp functions
Date
Msg-id 19417.1171729151@sss.pgh.pa.us
Whole thread Raw
In response to Re: patch adding new regexp functions  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: patch adding new regexp functions  (Jeremy Drake <pgsql@jdrake.com>)
Re: patch adding new regexp functions  (Jeremy Drake <pgsql@jdrake.com>)
List pgsql-patches
Peter Eisentraut <peter_e@gmx.net> writes:
> David Fetter wrote:
>> What is it about having the whole match, pre-match and post-match
>> available that you're objecting to?  Are you saying there aren't
>> common uses for any or all of these?  Regular expression users use
>> them all over the place,

> You keep saying that, and I keep saying please show a use case.

Maybe I'm missing something, but ISTM that given the ability to return
multiple match substrings there is no need for such features.  Given
an arbitrary regex 'xyz', write '^(.*)(xyz)(.*)$' and you'll get back
the pre-match, whole match, and post-match in addition to any
parenthesized substrings that 'xyz' contains.  If you only need some
of them, you can leave out the corresponding parts of this pattern.

So I'd vote against complicating the API in order to make special
provision for these results.  I claim that all we need is a function
taking (string text, pattern text, flags text) and returning either
array of text or setof text containing the matched substrings in
whatever order is standard (order by left-parenthesis position,
I think).  In the degenerate case where there are no parenthesized
subpatterns, just return the whole match as a single element.

As for the argument about array vs setof, I could see doing both to
end the argument of which one is really superior for any particular
problem.

            regards, tom lane

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: \prompt for psql
Next
From: Tom Lane
Date:
Subject: Re: \prompt for psql