On 09/23/2014 08:51 PM, Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
On Tue, Sep 23, 2014 at 12:46 PM, Heikki Linnakangas
<hlinnakan...@vmware.com> wrote:
Now, how do we make the tuplestores work similarly? Here's what I think we
should do:
Add a new p_tableref_hook function pointer, similar to p_paramref_hook.
Whenever the parser sees a RangeVar that it doesn't recognize (or actually,
I think it should call it *before* resolving regular tables, but let's
ignore that for now), it calls the p_tableref_hook. It can return a new
RelationParam node (similar to regular Param), which contains a numeric ID
for the table/tuplestore, as well as its tuple descriptor.
For the execution phase, add a new array of Tuplestorestates to
ParamListInfo. Similar to the existing array of ParamExternalDatas.
I haven't been following this issue closely, but this sounds like a
really nice design.
I'm on board with the parser hooks part of that. I don't especially agree
with the idea of a new sub-structure for ParamListInfo: if you do that you
will need a whole bunch of new boilerplate infrastructure to allocate,
copy, and generally manage that structure, for darn little gain. What I'd
suggest is just saying that some Params might have type INTERNAL with
Datum values that are pointers to tuplestores; then all you need to do is
remember which Param number has been assigned to the particular tuplestore
you want. There is already precedent for that in the recursive CTE code,
IIRC.
Works for me.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
