Re: WITH clause - Mailing list pgsql-hackers

From david@fetter.org (David Fetter)
Subject Re: WITH clause
Date
Msg-id 200312121936.hBCJaQAJ022349@fetter.org
Whole thread Raw
In response to Re: WITH clause  (Alvaro Herrera Munoz <alvherre@dcc.uchile.cl>)
List pgsql-hackers
In article <20031212190754.GA11548@dcc.uchile.cl> you wrote:
> On Fri, Dec 12, 2003 at 10:13:56AM -0800, David Fetter wrote:
> 
>> I'm looking to the SQL WITH clause as a way to get better regex
>> support in PostgreSQL.  I've been chatting a little bit about this,
>> and here's an idea for a behavior.  Implementation details TBD.

> I think you could be rather looking at keeping the regmatch_t * from
> RE_compile_and_execute somewhere in the TopTransactionContext, and
> create accessor functions to it.  You could do

> BEGIN;
> SELECT ... x ~ '([0-9]+)x([0-9]+)';
> SELECT regex_parens(1), regex_parens(2);
> COMMIT;

> Etc, you get the idea.  Of course you could only access the captured
> expressions from the last regex, and only within the same
> transaction block.

A couple of little issues with this:

1.  It's assuming there will be exactly one regular expression with
associated atoms.  This is probably fixable by making the function
take two arguments, and it would be really, really nice if these were
nameable.  F'rex, regex_matches(regex => 1, match => 2) or
regex_matches(regex => 'the_one_i_wanted', match => 'post')

2.  It doesn't allow for the regex atoms to be used in the SQL
statement.

BTW, I should have said "row-level environment variables" rather than
"statement-level environment variables," although some of the latter
would be nice, too :)

Cheers,
D
-- 
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100    cell: +1 415 235 3778

Sophomoric (adj.)  The itch to be unique.


pgsql-hackers by date:

Previous
From: "Roderick A. Anderson"
Date:
Subject: Re: 7.4 build problem on Linux Vserver
Next
From: Peter Eisentraut
Date:
Subject: Re: Resurrecting pg_upgrade