Re: [PATCHES] [HACKERS] writing new regexp functions
Jeremy Drake <[EMAIL PROTECTED]> writes: > On Wed, 7 Feb 2007, Tom Lane wrote: >> As of 8.2 there are. > Could you give me the name of one in pg_proc.h so I can see how I should > go about adding one there? select * from pg_proc where proargmodes is not null; regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] writing new regexp functions
On Wed, 7 Feb 2007, Tom Lane wrote: > Jeremy Drake <[EMAIL PROTECTED]> writes: > > * 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. > > As of 8.2 there are. Could you give me the name of one in pg_proc.h so I can see how I should go about adding one there? > If we are going to include these I would vote for core not contrib > status, exactly to avoid having to export those functions. OK, this patch will be my next project. -- History is curious stuff You'd think by now we had enough Yet the fact remains I fear They make more of it every year. ---(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
Re: [PATCHES] [HACKERS] writing new regexp functions
On Wed, Feb 07, 2007 at 09:23:58AM -0500, Tom Lane wrote: > Jeremy Drake <[EMAIL PROTECTED]> writes: > > * 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. > > As of 8.2 there are. > > If we are going to include these I would vote for core not contrib > status, exactly to avoid having to export those functions. +1 for core. :) Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] writing new regexp functions
Jeremy Drake <[EMAIL PROTECTED]> writes: > * 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. As of 8.2 there are. If we are going to include these I would vote for core not contrib status, exactly to avoid having to export those functions. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] writing new regexp functions
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
