Re: When do we lose column names?

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: When do we lose column names?
Дата
Msg-id 4F396BE8.40108@dunslane.net
обсуждение исходный текст
Ответ на Re: When do we lose column names?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: When do we lose column names?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

On 02/13/2012 11:00 AM, Tom Lane wrote:
> Robert Haas<robertmhaas@gmail.com>  writes:
>> On Sat, Feb 11, 2012 at 11:11 AM, Andrew Dunstan
>> <adunstan@postgresql.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: auto_explain produces invalid JSON
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: RFC: Making TRUNCATE more "MVCC-safe"