Skip site navigation (1) Skip section navigation (2)

Re: Confusing EXPLAIN output in case of inherited tables

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Adrian KlaverDate: 2012-01-30 17:03:47
Subject: Re: pg_dump -s dumps data?!
Previous:From: Jeff JanesDate: 2012-01-30 16:48:51
Subject: Re: Group commit, revised

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group