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
