Re: [HACKERS] writing new regexp functions - Mailing list pgsql-patches

From Jeremy Drake
Subject Re: [HACKERS] writing new regexp functions
Date
Msg-id Pine.BSO.4.64.0702021845540.28908@resin.csoft.net
Whole thread Raw
Responses Re: [HACKERS] writing new regexp functions  (David Fetter <david@fetter.org>)
List pgsql-patches
On Fri, 2 Feb 2007, David Fetter wrote:

> On Fri, Feb 02, 2007 at 08:56:31PM -0500, Tom Lane wrote:
> >
> > All of SQL's pattern match operators have the pattern on the right,
> > so my advice is to stick with that and try not to think about Perl
> > ;-)
>
> Perl provides inspiration, but here, consistency would help more than
> orderly imitation of how it does what it does.   And besides, when
> people really need Perl, they can pull it in as a PL :)

Alright, here is my code to date.  I have put the pattern after the string
in the split function, as discussed above.  The .tar.gz file expects to be
untarred in contrib/.  I have made some regression tests that can be run
using 'make installcheck' as normal for contrib.  I think they exercise
the corner cases in the code, but I may very well have missed some.  It
requires the (previously submitted) attached patch to core to compile, as
it takes advantage of new exported functions from
src/backend/utils/adt/regexp.c.

Let me know if you see any bugs or issues with this code, and I am open to
suggestions for further regression tests ;)


Things that I still want to look into:
* regexp flags (a la regexp_replace).

* maybe make regexp_matches return setof whatever, if given a 'g' flag
  return all matches in string.

* maybe a join function that works as an aggregate
   SELECT join(',', col) FROM tbl
  currently can be written as
   SELECT array_to_string(ARRAY(SELECT col FROM tbl), ',')




--
It was a virgin forest, a place where the Hand of Man had never set
foot.

Attachment

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] unixware and --with-ldap
Next
From: Heikki Linnakangas
Date:
Subject: Re: [pgsql-patches] Recalculating OldestXmin in a long-running vacuum