Re: Table as argument in postgres function - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Table as argument in postgres function
Date
Msg-id CAFj8pRBW5KQF_5-581TesCvfY-+9K7sL+dfAH-ZKNc+HV4huuA@mail.gmail.com
Whole thread Raw
In response to Re: Table as argument in postgres function  (Corey Huinker <corey.huinker@gmail.com>)
List 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 by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: PG 12 draft release notes
Next
From: "Matwey V. Kornilov"
Date:
Subject: Re: [PATCH v2] Introduce spgist quadtree @<(point,circle) operator