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
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? |
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 |