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