Re: OIDS (Re: [HACKERS] Well, then you keep your darn columns)

From: "Ricardo Coelho" <rcoelho(at)christus(dot)br>
To: <pgsql-hackers(at)postgreSQL(dot)org>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>
Subject: Re: OIDS (Re: [HACKERS] Well, then you keep your darn columns)
Date: 2000-01-26 20:46:52
Message-ID: 003701bf683e$7a904700$35fafdc8@px.com.br
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter,

Are you talking about make OID invisible ?
Please, don't do this. I have a good use of them to move backward and
forward in a set of rows
selected by interactive forms of any table.

Regards,

Ricardo Coelho.

----- Original Message -----
From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: The Hermit Hacker <scrappy(at)hub(dot)org>
Cc: Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>; <pgsql-hackers(at)postgreSQL(dot)org>
Sent: Wednesday, January 26, 2000 4:34 PM
Subject: OIDS (Re: [HACKERS] Well, then you keep your darn columns)

> On 2000-01-24, The Hermit Hacker mentioned:
>
> > Except, as Chris Bitmead brought up, OIDs appear to be a key requirement
> > in ODBMSs ... so, if we want to go what I *think* is 'next generation',
> > OIDs have to be kept ...
>
> Independent of everything else I would like to point out that although
> oids do appear in a central role in the theory of object oriented
> databases they are still not a user-level feature. The system uses them to
> in essence do what some people already do with them now: use them as links
> in foreign key settings. This sort of scheme is supposed to eliminate the
> need for costly joins, since you already know the location of the data
> (assuming that you have a scheme to map the oid to the storage location).
>
> This past summer this sort of idea was discussed around these parts and
> most of us came to the conclusion that a) OODBs are a pipe-dream at this
> point in time, and b) this is not worth doing in PostgreSQL as it stands.
> If we wanna become an OODBs we might as well say that now so we can start
> by dropping SQL and the optimizer and the storage manager -- okay, I'm
> being sarcastic (about OODBs).
>
> However, once again, users would have no knowledge of these "oids". The
> system is free to do whatever it wants in order to do its thing, in
> particular it is free to *change* oids when it needs it (because when it
> copies the data elsewhere it presumably needs to tag the location
> differently).
>
> Our oids are something different (though not sure what), PostgreSQL is
> something different. I am by all means against breaking what oids
> represent now, but incidentally I am also against them becoming (being) a
> user-level feature.
>
> --
> Peter Eisentraut Sernanders väg 10:115
> peter_e(at)gmx(dot)net 75262 Uppsala
> http://yi.org/peter-e/ Sweden
>
>
>
> ************

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2000-01-26 22:23:24 Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace
Previous Message Ross J. Reedstrom 2000-01-26 20:21:16 Re: [HACKERS] Inheritance, referential integrity and other constraints