From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Confusing EXPLAIN output in case of inherited tables |
Date: | 2012-01-30 16:56:27 |
Message-ID: | 16176.1327942587@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2012-01-30 17:03:47 | Re: pg_dump -s dumps data?! |
Previous Message | Jeff Janes | 2012-01-30 16:48:51 | Re: Group commit, revised |