Re: [HACKERS] patch: function xmltable - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] patch: function xmltable
Date
Msg-id CAFj8pRCrj1J6FejdgOCbWjH3U3ATGD_zUE6Q3k7ydkPWpHeGnA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] patch: function xmltable  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers


2017-01-25 23:33 GMT+01:00 Andres Freund <andres@anarazel.de>:
On 2017-01-25 22:51:37 +0100, Pavel Stehule wrote:
> 2017-01-25 22:40 GMT+01:00 Andres Freund <andres@anarazel.de>:
> > > I afraid when I cannot to reuse a SRF infrastructure, I have to
> > reimplement
> > > it partially :( - mainly for usage in "ROWS FROM ()"
> >
>
> The TableExpr implementation is based on SRF now. You and Alvaro propose
> independent implementation like generic executor node. I am sceptic so
> FunctionScan supports reading from generic executor node.

Why would it need to?

Simply - due consistency with any other functions that can returns rows.

Maybe I don't understand to Alvaro proposal well - I have a XMLTABLE function - TableExpr that looks like SRF function, has similar behave - returns more rows, but should be significantly different implemented, and should to have different limits - should not be used there and there ... It is hard to see consistency there for me.

Regards

Pavel


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superusercheck
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument