Re: Patch: clean up addRangeTableEntryForFunction
От
Tom Lane
Тема
Re: Patch: clean up addRangeTableEntryForFunction
Дата
Msg-id
4902.1358913738@sss.pgh.pa.us
Ответ на
Patch: clean up addRangeTableEntryForFunction (David Fetter)
Список
Дерево обсуждения
Patch: clean up addRangeTableEntryForFunction David Fetter <david@fetter.org>
Re: Patch: clean up addRangeTableEntryForFunction Tom Lane <tgl@sss.pgh.pa.us>
Re: Patch: clean up addRangeTableEntryForFunction David Fetter <david@fetter.org>
Re: Patch: clean up addRangeTableEntryForFunction Craig Ringer <craig@2ndQuadrant.com>
Re: Patch: clean up addRangeTableEntryForFunction Robert Haas <robertmhaas@gmail.com>
Re: Patch: clean up addRangeTableEntryForFunction "Etsuro Fujita" <fujita.etsuro@lab.ntt.co.jp>
David Fetter writes: > I've been working with Andrew Gierth (well, mostly he's been doing the > work, as usual) to add WITH ORDINALITY as an option for set-returning > functions. In the process, he found a minor opportunity to clean up > the interface for $SUBJECT, reducing the call to a Single Point of > Truth for lateral-ness, very likely improving the efficiency of calls > to that function. As I mentioned in our off-list discussion, I think this is going in the wrong direction. It'd make more sense to me to get rid of the RangeFunction parameter, instead passing the two fields that addRangeTableEntryForFunction actually uses out of that. If we do what you have here, we'll be welding together the alias and lateral settings for the new RTE; which conceivably some other caller would want to specify in a different way. As a comparison point, you might want to look at the various calls to addRangeTableEntryForSubquery: some of those pass multiple fields out of the same RangeSubselect, and some do not. regards, tom lane
В списке pgsql-hackers по дате отправления