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

From David Fetter
Subject Re: writing new regexp functions
Date
Msg-id 20070202051142.GE3882@fetter.org
Whole thread Raw
In response to Re: writing new regexp functions  (Jeremy Drake <pgsql@jdrake.com>)
Responses Re: writing new regexp functions  (Jeremy Drake <pgsql@jdrake.com>)
List pgsql-hackers
On Thu, Feb 01, 2007 at 05:11:30PM -0800, Jeremy Drake wrote:
> On Thu, 1 Feb 2007, Tom Lane wrote:
> 
> > Jeremy Drake <pgsql@jdrake.com> writes:
> > > Is there some specific reason that these functions are static,
> >
> > Yeah: not cluttering the global namespace.
> 
> > Is there a reason for not putting your new code itself into regexp.c?
> 
> Not really, I just figured it would be cleaner/easier to write it as an
> extension.  I also figure that it is unlikely that every regexp function
> that anyone could possibly want will be implemented in core in that one
> file.  If anyone writes an extension like this, they would need to
> duplicate a good amount of code in order to do so, that would make more
> difficulty in maintaining the code if it should need to change.  It also
> makes developing a new function a lot easier, no need to re-initdb to add
> the function, no need to relink the postmaster and restart it every time
> the function changes.
> 
> Anyway, the particular thing I was writing was a function like
> substring(str FROM pattern) which instead of returning just the
> first match group, would return an array of text containing all of
> the match groups.

That'd be great!  People who use dynamic languages like Perl would
feel much more at home having access to all the matches.  While you're
at it, could you could make pre-match and post-match (optionally--I
know it's expensive) available?

Cheers,
D
-- 
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666                             Skype: davidfetter

Remember to vote!


pgsql-hackers by date:

Previous
From: ITAGAKI Takahiro
Date:
Subject: Re: Estimation error in n_dead_tuples
Next
From: Bruce Momjian
Date:
Subject: Re: column ordering, was Re: [PATCHES] Enums patch v2