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
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
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 th
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.
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 fig
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
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
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 patter
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
> > --+---+-+
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 chang
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
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 return
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 contai
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 no
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 w
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
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 wi
17 matches
Mail list logo
