Re: [PATCHES] [HACKERS] writing new regexp functions

2007-02-07 Thread Jeremy Drake
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

Re: [PATCHES] [HACKERS] writing new regexp functions

2007-02-07 Thread Tom Lane
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

Re: [PATCHES] [HACKERS] writing new regexp functions

2007-02-07 Thread David Fetter
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

Re: [PATCHES] [HACKERS] writing new regexp functions

2007-02-07 Thread Jeremy Drake
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

Re: [PATCHES] [HACKERS] writing new regexp functions

2007-02-07 Thread Tom Lane
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

Re: [HACKERS] writing new regexp functions

2007-02-02 Thread Jeremy Drake
On Thu, 1 Feb 2007, David Fetter wrote: Yes, although it might have the same name, as in regex_match(pattern TEXT, string TEXT, return_pre_and_post BOOL). The data structure could be something like TYPE matches ( prematch TEXT, matchTEXT[], postmatch TEXT ) I just

Re: [HACKERS] writing new regexp functions

2007-02-02 Thread Jeremy Drake
On Fri, 2 Feb 2007, Jeremy Drake wrote: jeremyd=# select * from regexp_matches('foobarbequebaz', $re$(bar)(beque)$re$, false); prematch | fullmatch | matches | postmatch --+---+-+--- \N | \N| {bar,beque} | \N (1 row) I just changed

Re: [HACKERS] writing new regexp functions

2007-02-02 Thread David Fetter
On Fri, Feb 02, 2007 at 12:54:30AM -0800, Jeremy Drake wrote: On Fri, 2 Feb 2007, Jeremy Drake wrote: jeremyd=# select * from regexp_matches('foobarbequebaz', $re$(bar)(beque)$re$, false); prematch | fullmatch | matches | postmatch --+---+-+---

Re: [HACKERS] writing new regexp functions

2007-02-02 Thread Jeremy Drake
On Fri, 2 Feb 2007, Jeremy Drake wrote: I just coded up for this: CREATE FUNCTION regexp_matches(IN str text, IN pattern text) RETURNS text[] AS 'MODULE_PATHNAME', 'regexp_matches' LANGUAGE C IMMUTABLE STRICT; CREATE FUNCTION regexp_matches( IN str text, IN pattern text,

Re: [HACKERS] writing new regexp functions

2007-02-02 Thread Tom Lane
Jeremy Drake [EMAIL PROTECTED] writes: I want to ask, should I break with following substring's precedent, and put the pattern first (as most people probably would expect), or should I break with perl's precedent and put the pattern second (to behave like substring)? All of SQL's pattern

Re: [HACKERS] writing new regexp functions

2007-02-02 Thread David Fetter
On Fri, Feb 02, 2007 at 08:56:31PM -0500, Tom Lane wrote: Jeremy Drake [EMAIL PROTECTED] writes: I want to ask, should I break with following substring's precedent, and put the pattern first (as most people probably would expect), or should I break with perl's precedent and put the

[HACKERS] writing new regexp functions

2007-02-01 Thread Jeremy Drake
I am wanting to write some new C functions which leverage postgresql's existing regexp code in an extension module. I notice that the functions RE_compile_and_cache and RE_compile_and_execute in src/backend/util/regexp.c contain the code necessary to connect the regexp code in src/backend/regex

Re: [HACKERS] writing new regexp functions

2007-02-01 Thread Tom Lane
Jeremy Drake [EMAIL PROTECTED] writes: Is there some specific reason that these functions are static, Yeah: not cluttering the global namespace. I'm not excited about exporting everything that anybody could possibly want access to; that just makes it harder to maintain the code. When you see a

Re: [HACKERS] writing new regexp functions

2007-02-01 Thread Jeremy Drake
On Thu, 1 Feb 2007, Tom Lane wrote: Jeremy Drake [EMAIL PROTECTED] 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

Re: [HACKERS] writing new regexp functions

2007-02-01 Thread David Fetter
On Thu, Feb 01, 2007 at 05:11:30PM -0800, Jeremy Drake wrote: On Thu, 1 Feb 2007, Tom Lane wrote: Jeremy Drake [EMAIL PROTECTED] 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

Re: [HACKERS] writing new regexp functions

2007-02-01 Thread Jeremy Drake
On Thu, 1 Feb 2007, David Fetter wrote: On Thu, Feb 01, 2007 at 05:11:30PM -0800, Jeremy Drake wrote: 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

Re: [HACKERS] writing new regexp functions

2007-02-01 Thread David Fetter
On Thu, Feb 01, 2007 at 10:16:54PM -0800, Jeremy Drake wrote: On Thu, 1 Feb 2007, David Fetter wrote: On Thu, Feb 01, 2007 at 05:11:30PM -0800, Jeremy Drake wrote: Anyway, the particular thing I was writing was a function like substring(str FROM pattern) which instead of returning just