Bruce Momjian wrote:
>>As for pg_description, the change in primary key is unfortunate but
>>*necessary*. I don't foresee us reversing it. The consensus view as
>>I recall it was that we wanted to go over to a separate OID generator
>>per table in some future release, which fits right in with the new
>>structure of pg_description, but is entirely unworkable with the old.
>>
This is the clash of views between OO and R parts of ORDB - tho OO part
_needs_ oid and a better support structure for OIDs, while the classical
RDB
(aka. bean-counting ;) part has not need for them..
It's not the right time to discuss it during beta time, but the pendulum
has been
swinging heavily to the "classic RDB" side of thing in recent years for
PostgreSQL,
while it has been already going the other way for at least Oracle and
Informix(Illustra)
at least.
If we want to keep up the general copycat image of free software we of
course can,
but I would much more like us to "return to the roots" of postgres and
be in/near the
forefront for a change ;) . That would mean at least stronger support
for OO, and
perhaps also restoring support for (per table/optional) time travel.
There were possibly more nice features that could be restored...
>
>In other words, a separate sequence for each system table, right? Is
>that where we are headed? We could still call the column oid and
>queries would continue to work. I don't think there are many
>cases where the oid is used to find a particular table, except my
>/contrib/findoidjoins, which can be removed.
>
In the 7.x.x series even a system column tableoid was added that can be
used to
determine the table the tuple came form. I guess it was in preparation
for implementing
SQL99's CREATE TABLE x UNDER y construct in one table, perhaps in a way that
would allow fast DROP COLUMN's (i.e separation of physical/logical
column order)
----------------
Hannu
