Re: When do we lose column names?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <adunstan(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: When do we lose column names?
Date: 2012-02-13 16:00:53
Message-ID: 10946.1329148853@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Feb 11, 2012 at 11:11 AM, Andrew Dunstan
> <adunstan(at)postgresql(dot)org> wrote:
>> Do we actually need to bother with these cases?

> In flatten_join_alias_vars_mutator(), we've got a RangeTblEntry to
> work with. I think the column names are to be found in the alias
> and/or eref attributes of the RangeTblEntry.

The eref names are the ones to use. alias just records the original AS
clause (if any) attached to the RTE, which is mostly useful only for
reverse-listing the query.

> In adjust_appendrel_attrs_mutator(), we have a list, translated_vars,
> whose order matches the column order of the parent rel. If we had the
> parent's RangeTblEntry, we could probably precede as in the previous
> case. But the AppendRelInfo only contains the index of the RT. Maybe
> we can figure out a way to use rt_fetch to get the RangeTblEntry
> itself, but that requires a pointer to the range table itself, which
> we haven't got.

This is surely fixable by passing a bit more information down. If you
(Andrew) have something that covers everything but this issue, pass it
over and I'll take a whack at it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-02-13 16:15:10 Re: auto_explain produces invalid JSON
Previous Message Kevin Grittner 2012-02-13 15:48:48 Re: RFC: Making TRUNCATE more "MVCC-safe"