Re: Patch: clean up addRangeTableEntryForFunction

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Fetter <david(at)fetter(dot)org>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch: clean up addRangeTableEntryForFunction
Date: 2013-01-23 04:02:18
Message-ID: 4902.1358913738@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Fetter <david(at)fetter(dot)org> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-01-23 04:17:27 Re: Event Triggers: adding information
Previous Message Stephen Frost 2013-01-23 03:52:20 Re: Prepared statements fail after schema changes with surprising error