Re: writing new regexp functions - Mailing list pgsql-hackers

From Jeremy Drake
Subject Re: writing new regexp functions
Date
Msg-id Pine.BSO.4.64.0702020048510.28908@resin.csoft.net
Whole thread Raw
In response to Re: writing new regexp functions  (Jeremy Drake <pgsql@jdrake.com>)
Responses Re: writing new regexp functions  (David Fetter <david@fetter.org>)
List pgsql-hackers
On Fri, 2 Feb 2007, Jeremy Drake wrote:

> jeremyd=# select * from regexp_matches('foobarbequebaz',
> $re$(bar)(beque)$re$, false);
>  prematch | fullmatch |   matches   | postmatch
> ----------+-----------+-------------+-----------
>  \N       | \N        | {bar,beque} | \N
> (1 row)

I just changed this to fill in fullmatch when the bool is false, so this
one would look like:prematch | fullmatch |   matches   | postmatch
----------+-----------+-------------+-----------\N       | barbeque  | {bar,beque} | \N
(1 row)

I also removed my check for capture groups, since in this setup you could
get useful output without any.  I am still trying to decide whether or not
to add back an error if you called the no-bool version which just returns
the array, and you do not have any capture groups.  ISTM this is likely an
oversight on the query author's part, and it would be helpful to alert him
to this.

If you have no capture groups, the matches array is empty (not null).  If
the match happened at the start of the string, the prematch is an empty
string, and if the match happened at the end of the string, the postmatch
is an empty string.


> Reasonable?

-- 
It's odd, and a little unsettling, to reflect upon the fact that
English is the only major language in which "I" is capitalized; in many
other languages "You" is capitalized and the "i" is lower case.    -- Sydney J. Harris


pgsql-hackers by date:

Previous
From: NikhilS
Date:
Subject: Re: --enable-debug does not work with gcc
Next
From: Michael Meskes
Date:
Subject: Re: Why is ecpg segfaulting on buildfarm member "clownfish"?