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.c outside 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 could stay 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. ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match