Re: When do we lose column names?

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

On 02/13/2012 11:00 AM, Tom Lane wrote:
> 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.

What I have fixes one of the three cases I have identified that appear
to need fixing, the one that caused the json tests to crash with your
original partial patch. See
<https://bitbucket.org/adunstan/pgdevel/changesets/tip/rowexprs>. I
won't have time to return to this for a few days. The two remaining
cases should be fairly independent I think. If you don't get to this
before then I'll look at the flatten_join_alias_vars_mutator case again
and try to fix it based on the above, and then give you what I've got.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2012-02-13 20:09:07 Re: RFC: Making TRUNCATE more "MVCC-safe"
Previous Message Andrew Dunstan 2012-02-13 19:11:54 Re: auto_explain produces invalid JSON