Re: Confusing EXPLAIN output in case of inherited tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Confusing EXPLAIN output in case of inherited tables
Date
Msg-id 16176.1327942587@sss.pgh.pa.us
Whole thread Raw
In response to Re: Confusing EXPLAIN output in case of inherited tables  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: Confusing EXPLAIN output in case of inherited tables
Re: Confusing EXPLAIN output in case of inherited tables
List pgsql-hackers
Ashutosh Bapat <ashutosh.bapat@enterprisedb.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


pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Group commit, revised
Next
From: Robert Haas
Date:
Subject: Re: patch for parallel pg_dump