Re: [HACKERS] Re: PRIMARY KEY & INHERITANCE (fwd)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au>
Cc: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, pgsql-general(at)hub(dot)org, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Re: PRIMARY KEY & INHERITANCE (fwd)
Date: 2000-07-20 04:22:49
Message-ID: 22965.964066969@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chris Bitmead 2000-07-20 04:56:42 Re: [HACKERS] Re: PRIMARY KEY & INHERITANCE (fwd)
Previous Message Tom Lane 2000-07-20 04:12:32 Re: unique constraint - bug?

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-07-20 04:50:56 Re: About these IPC parameters
Previous Message Larry Rosenman 2000-07-20 02:14:06 mac.c