Tom Lane wrote:
>
> Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
> > ... The attnum and the name should
> > probably be individual to each class in the hierarchy. (The name should
> > be individual to support subclass renaming to avoid naming conflicts,
> > like in the draft SQL3 and Eiffel). If it is in two parts then using the
> > oid of the common part would make it easy for your purposes.
>
> This bothers me. Seems like you are saying that a subclass's column
> might not match the parent's by *either* name or column position, but
> nonetheless the system will know that this subclass column is the same
> as that parent column. No doubt we could implement that by relying on
> OIDs of pg_attribute rows, but just because it's implementable doesn't
> make it a good idea. I submit that this is too confusing to be of
> any practical use. There should be a *user-visible* connection between
> parent and child column, not some magic under-the-hood connection.
> IMHO it ought to be the column name.
When you multiple inherit from unrelated base classes you need a
conflict
resolution mechanism. That's why it can't be the name. The SQL3 draft
recognised this.
Many programming languages deal with this issue without undue confusion.
To provide mapping to these programming languages such a conflict
resolution mechanism becomes necessary.
