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?
|
Список | 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 по дате отправления: