Re: [HACKERS] patch: function xmltable

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] patch: function xmltable
Дата
Msg-id CAFj8pRCrj1J6FejdgOCbWjH3U3ATGD_zUE6Q3k7ydkPWpHeGnA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] patch: function xmltable  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superusercheck
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument