Re: [PATCHES] writing new regexp functions - Mailing list pgsql-hackers

From Jeremy Drake
Subject Re: [PATCHES] writing new regexp functions
Date
Msg-id Pine.BSO.4.64.0702070010470.28908@resin.csoft.net
Whole thread Raw
In response to Re: writing new regexp functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] writing new regexp functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, 4 Feb 2007, David Fetter wrote:

> On Fri, Feb 02, 2007 at 07:01:33PM -0800, Jeremy Drake wrote:
>
> > Let me know if you see any bugs or issues with this code, and I am
> > open to suggestions for further regression tests ;)

I have not heard anything, so I guess at this point I should figure out
where to go next with this.  I see a couple options:

* Set this up as a pgfoundry project or contrib.  This would require merging the patch to expose some functions from
regexp.coutside that file, which has raised some concerns about maintainability.
 

* Put together a patch to add these functions to core.  I could put them directly in regexp.c, so the support functions
couldstay static.  My concern here is that I don't know if there are any functions currently in core with OUT
parameters. I don't know the acceptable style for handling this: OUT parameters, a named composite type, ...?
 

Does anyone have any opinions either way, as to how I should proceed
from here?



> > * 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), ',')
>
> The array_accum() aggregate in the docs works OK for this purpose.

I have decided not to pursue this function, I think the array construct,
or the array_accum option, is about the best possible currently.  If it
should become possible in the future to write aggregates with a non-sql
state type (structs with pointers) it may be worthwhile to re-evaluate
this.


-- 
The cost of living hasn't affected its popularity.


pgsql-hackers by date:

Previous
From: Markus Schiltknecht
Date:
Subject: Re: Proposal: Commit timestamp
Next
From: "Pavel Stehule"
Date:
Subject: Re: Proposal: TABLE functions