On Tue, Sep 23, 2014 at 1:51 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> 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.
Studying this proposed design a bit further, I am a little fuzzy on what is supposed to happen in this design during parse analysis. In Kevin's current code, after checking whether a RangeVar might be a CTE reference and before deciding that it must be a table reference, scanNameSpaceForTsr() is used to check whether there's a tuplestore by that name and, if so, then we insert a RTE with type RTE_TUPLESTORE which references the tuplestore by name. To me, the obvious thing to do here seems to be to instead call p_tableref_hook and let it return a suitable RangeTblRef (or NULL if it wishes to take no action). In the case where the hook wants to redirect the use of that name to a tuplestore, it can add a range-table entry of type RTE_TUPLESTORE, and that entry can store a parameter-index rather than, as in the current design, a name. But then where does Heikki's notion of a RelationParam get used? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers