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
whenthe inheritance is expanded (expand_inherited_rtentry). So, there is not question of generating them so as to not
collidewith other aliases in the query. However I did not find answers to these questions<br /> 1. What is the use of
erefin case of relation when the relation name itself can be provided by the reloid?<br />2. Can we use schema
qualifiedrelation name in get_from_clause_item() and get_variable() instead of use eref->aliasname. I have noticed
thatthe logic in get_rte_attribute_name() gives preference to the column names in catalog tables over
eref->colnames.<br/><br />Anyone?<br /><br /><div class="gmail_quote">On Mon, Jan 30, 2012 at 10:26 PM, Tom Lane
<spandir="ltr"><<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Ashutosh Bapat
<<ahref="mailto:ashutosh.bapat@enterprisedb.com">ashutosh.bapat@enterprisedb.com</a>> writes:<br /> > So, as I
understandwe have two problems here<br /> > 1. Prefixing schemaname to the fake alises if there is another RTE
with<br/> > same name. There may not be a relation with that name (fake alias name<br /> > given) in the schema
chosenas prefix.<br /> > 2. Fake aliases themselves can be conflicting.<br /><br /></div>Well, the issue is more
thata fake alias might unintentionally collide<br /> with a regular alias elsewhere in the query.  There's no guard
against<br/> that in the current behavior, and ISTM there needs to be.<br /><br /> The one possibly-simplifying thing
aboutthis whole issue is that we<br /> needn't cater for references that couldn't have been made in the<br /> original
query. For instance, if the inner and outer queries both have<br /> explicit aliases "tx", it's impossible for the
innerquery to have<br /> referred to any columns of the outer "tx" --- so we don't have to try to<br /> make it
possiblein the dumped form.<br /><div class="im"><br /> > If I understand correctly, if we solve the second problem,
firstproblem<br /> > will not occur. Is that correct?<br /><br /></div>I don't believe that the problem has anything
todo with the names of<br /> other tables that might happen to exist in the database.  It's a matter<br /> of what RTE
names/aliasesare exposed for variable references in<br /> different parts of the query.<br /><br />                    
  regards, tom lane<br /></blockquote></div><br /><br clear="all" /><br />-- <br />Best Wishes,<br />Ashutosh Bapat<br
/>EntepriseDBCorporation<br />The Enterprise Postgres Company<br /><br />