Heikki Linnakangas <hlinnakan...@vmware.com> writes: > On 10/22/2014 11:10 PM, Robert Haas wrote: >> 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?
> I was thinking that the hook would return a RelationParam. When parse > analysis sees the returned RelationParam, it adds an entry for that to > the range table, and creates the RangeTblRef for it. The way you > describe it works too, but manipulating the range table directly in the > hook seems a bit too low-level. The problem with that idea is that then the API for the hook has to cover every possible sort of RTE that hooks might wish to create; I see no reason to restrict them to creating just one kind. I agree that the hook should avoid *physically* manipulating the rangetable, but it seems reasonable to expect that it can call one of the addRangeTableEntryXXX functions provided by parse_relation.c, and then return a RangeTblEntry* gotten that way. So hooks would have an API more or less equivalent to, eg, transformRangeFunction(). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers