On Sat, Feb 11, 2012 at 11:11 AM, Andrew Dunstan
<adunstan@postgresql.org> wrote:
>>>> Other candidates I have found that don't set colnames and should
>>>> probably use dummy names are:
>>>> * src/backend/parser/gram.y (row: production)
>>>> *
>>>> src/backend/optimizer/prep/prepunion.c:adjust_appendrel_attrs_mutator()
>>>> * src/backend/optimizer/util/var.c:flatten_join_alias_vars_mutator()
>>>
>>> Hm, can't the last two get real column names from somewhere?
>>
>> Possibly. I'll dig a bit deeper.
>
> I've had a look at these two. It's at least not obvious to me how to do this
> simply, if at all. In the last case it looks like we'd need to process the
> object recursively just like we do to extract the field values, and I don't
> know where to get them in the appendrel case at all, possibly because I'm
> not very familiar with this code.
>
> Do we actually need to bother with these cases? The regression tests pass
> without touching them, either because they don't matter or because we don't
> have a test for these cases that would tickle the assertion that was
> failing. If they don't matter, would it not be better just to note that in
> the code rather than building a list of field names for no good purpose?
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. Each of those is an
Alias object, which is defined like this:
typedef struct Alias
{ NodeTag type; char *aliasname;
/* aliased rel name (never qualified) */ List *colnames; /* optional list of column aliases */
} Alias;
I'm not sure whether we should look at rte->eref.colnames,
rte->alias.colnames, or both.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
