Re: Confusing EXPLAIN output in case of inherited tables

Looking at the code, it seems that the fake aliases (eref) for relations
(may be views as well) are not generated per say, but they do not get
changed when the relation name changes OR in case of inherited tables, they
do not get changed when the inheritance is expanded
(expand_inherited_rtentry). So, there is not question of generating them so
as to not collide with other aliases in the query. However I did not find
answers to these questions
1. What is the use of eref in case of relation when the relation name
itself can be provided by the reloid?
2. Can we use schema qualified relation name in get_from_clause_item() and
get_variable() instead of use eref->aliasname. I have noticed that the
logic in get_rte_attribute_name() gives preference to the column names in
catalog tables over eref->colnames.

Anyone?

On Mon, Jan 30, 2012 at 10:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> writes:
> > So, as I understand we have two problems here
> > 1. Prefixing schemaname to the fake alises if there is another RTE with
> > same name. There may not be a relation with that name (fake alias name
> > given) in the schema chosen as prefix.
> > 2. Fake aliases themselves can be conflicting.
>
> Well, the issue is more that a fake alias might unintentionally collide
> with a regular alias elsewhere in the query. There's no guard against
> that in the current behavior, and ISTM there needs to be.
>
> The one possibly-simplifying thing about this whole issue is that we
> needn't cater for references that couldn't have been made in the
> original query. For instance, if the inner and outer queries both have
> explicit aliases "tx", it's impossible for the inner query to have
> referred to any columns of the outer "tx" --- so we don't have to try to
> make it possible in the dumped form.
>
> > If I understand correctly, if we solve the second problem, first problem
> > will not occur. Is that correct?
>
> I don't believe that the problem has anything to do with the names of
> other tables that might happen to exist in the database. It's a matter
> of what RTE names/aliases are exposed for variable references in
> different parts of the query.
>
> regards, tom lane
>

--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company