Simon Riggs wrote:
On Mon, 2008-07-07 at 16:26 -0700, David Fetter wrote:
On Mon, Jul 07, 2008 at 06:46:29PM -0400, Andrew Dunstan wrote:
For the record, I agree with Jan's suggestion of passing a pointer
to the parse tree, and offline gave David a suggestion verbally as
to how this could be handled for PL/PerlU.
I don't think we should be tied too closely to a string
representation, although possibly the first and simplest callback
function would simply stringify the quals.
As I understand Jan's plan, the idea is to create a new relkind with
an exit to user code at leaf nodes in the plan tree. This would
require an API design for both user C code and for each PL to use, but
would then allow PostgreSQL's optimizer to work on JOINs, etc.
Jan, have I got that right so far? Do you have something in the way
of a rough patch, docs, etc. for this?
It sounds like we can make it happen as text for other DBMS and as plan
nodes for PostgreSQL, which is the best solution all round.
Personally not too worried which way we do this - as long as we do it
for 8.4 :-) It's obviously happening in the background, so I'll leave it
alone.
I think the concept involving the plan tree is gold. Hannu Krosing
mentioned some idea like that recently as well.
If the function had the chance to tell the planner how it is gonna
operate (e.g produces sorted output, etc.) it would be perfect.
The golden thing here would be if we could teach a function whether it
is " STREAMABLE | NOT STREAMABLE". streamable would make sure that we
don't have to materialize the output of a set returning function. this
would allow google-like analysis in postgresql easily by allowing to
fetch data from any amount of data from any data source.
best regards,
hans
--
Cybertec Schönig & Schönig GmbH
PostgreSQL Solutions and Support
Gröhrmühlgasse 26, A-2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql-support.de, www.postgresql-support.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
