Re: Table as argument in postgres function

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Table as argument in postgres function
Дата
Msg-id CAFj8pRBW5KQF_5-581TesCvfY-+9K7sL+dfAH-ZKNc+HV4huuA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Table as argument in postgres function  (Corey Huinker <corey.huinker@gmail.com>)
Список pgsql-hackers


út 21. 5. 2019 v 9:04 odesílatel Corey Huinker <corey.huinker@gmail.com> napsal:

Is there anything preventing us from having the planner resolve object names from strings?

The basic problem is fact so when you use PREPARE, EXECUTE protocol, you has not parameters in planning time.

I agree that it defeats PREPARE as it is currently implemented with PQprepare(), and it would never be meaningful to have a query plan that hasn't finalized which objects are involved.

But could it be made to work with PQexecParams(), where the parameter values are already provided?

Could we make a version of PQprepare() that takes an extra array of paramValues for object names that must be supplied at prepare-time?

I think so it is possible, but there is a question how much this design uglify source code. Passing query parameters is maybe too complex already.

Second question. I am not sure if described feature is some different. ANSI SQL 2016 knows Polymorphic table functions - looks like that. For me, I would to see implementation of PTF instead increasing complexity of work with parameters.







 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Haribabu Kommi
Дата:
Сообщение: Re: PG 12 draft release notes
Следующее
От: "Matwey V. Kornilov"
Дата:
Сообщение: Re: [PATCH v2] Introduce spgist quadtree @<(point,circle) operator