On Wed, Feb 1, 2012 at 11:01 PM, Robert Haas
<robertmhaas@gmail.com> wrote:
On Wed, Feb 1, 2012 at 12:23 PM, Tom Lane <
tgl@sss.pgh.pa.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 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.
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
