Re: Confusing EXPLAIN output in case of inherited tables

On Wed, Feb 1, 2012 at 11:01 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Feb 1, 2012 at 12:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > On the other hand it isn't
> > all that far beyond what I had in mind of inventing relation aliases
> > to cure relation-name conflicts. Should we take the existence of such
> > cases as evidence that we shouldn't try hard in this area? It seems
> > reasonable to me to try to handle relation renames but draw the line
> > at disambiguating column names. But others might find that distinction
> > artificial.
>
> I sure do.
>
> I mean, in Oracle, if you rename a table or column involved in a view,
> then the view breaks. Blammo! The reference is by object name, not
> by some internal identifier a la OID. If you put back an object with
> the correct name (either the original one or a different one), you can
> re-enable the view.
>
> We've decide that we don't want that behavior: instead, our references
> are to the object itself rather than to the name of the object.
> Renaming the object doesn't change what the reference points to. But
> given that position, it seems to me that we ought to be willing to
> work pretty hard to make sure that when we dump-and-reload the
> database, things stay sane. Otherwise, we're sort of in this
> unsatisfying in-between place where references are *mostly* by
> internal identifier but everyone once in a while it falls apart and
> name collisions can break everything. Yech!
>
>
For me the relation names problem and column aliases problems are two
independent problems. While the first one looks easy to fix, the other
problem may be hard to solve. We can solve the first problem and things
will be "better" than what we have today. If you agree, I will provide a
patch to fix the relation names problems by ignoring the eref (for
RTE_RELATION only) in ruleutils.

> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

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