Re: Concerns about this release

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