Thread

1. Re: [QUESTIONS] Arrays (inserting and removing)

   Bryan Basham <basham@bhi.com> — 1998-01-15T18:39:16Z

   > OIDs are a bastardization of the relational model.  If you have to keep
   > them, then do so, but their use should be SEVERELY discouraged.
   
   Explain yourself, please.
   
   In my opinion, I view the OID in the same way as I view the SERIAL datatype
   in Informix.  It is usually a primary key field in a table.  On an insert,
   the DBMS will increment the current serial-maximum (for that table) and insert
   the new serial value into that field; thus creating a unique identifier.
   
   There are differences between OID and SERIAL.  The main difference is that
   the OID field (always called 'oid') is always present whereas a DB designer
   explicitly creates 'id' fields (of SERIAL type).  Thus, postgresql treats
   every table as an object (which is not always the case).
   
   Is the SERIAL datatype part of the SQL-92 standard?  Does PostgreSQL plan
   to support SERIAL in the future.  This would be an acceptable replacement
   for the OID.
   
   -Bryan Basham
   
   

2. Re: [HACKERS] Re: [QUESTIONS] Arrays (inserting and removing)

   Marc G. Fournier <scrappy@hub.org> — 1998-01-15T18:48:24Z

   On Thu, 15 Jan 1998, Bryan Basham wrote:
   
   > 
   > > OIDs are a bastardization of the relational model.  If you have to keep
   > > them, then do so, but their use should be SEVERELY discouraged.
   > 
   > Explain yourself, please.
   > 
   > In my opinion, I view the OID in the same way as I view the SERIAL datatype
   > in Informix.  It is usually a primary key field in a table.  On an insert,
   > the DBMS will increment the current serial-maximum (for that table) and insert
   > the new serial value into that field; thus creating a unique identifier.
   > 
   > There are differences between OID and SERIAL.  The main difference is that
   > the OID field (always called 'oid') is always present whereas a DB designer
   > explicitly creates 'id' fields (of SERIAL type).  Thus, postgresql treats
   > every table as an object (which is not always the case).
   
   	Major problem with OID: OIDs are sequenced across the database,
   not the table.  ie. tableA inserts with OID #1, tableB inserts with OID
   #2, tableA inserts next record with OID #3, tableC then gets #4, etc...
   
   	And...# of OIDs is finite...so if you have a lot of tables with
   alot of data in each...you run the risk of running out.
   
   	In this sense, sequences are the better alternative, but again,
   they are a newer feature to PostgreSQL then the code that I wrote using
   OIDs
   
   
   
   

3. Re: [HACKERS] Re: [QUESTIONS] Arrays (inserting and removing)

   neil d. quiogue <neil@iphil.net> — 1998-01-16T01:04:10Z

   On Thu, 15 Jan 1998, The Hermit Hacker wrote:
   
   > 	Major problem with OID: OIDs are sequenced across the database,
   > not the table.  ie. tableA inserts with OID #1, tableB inserts with OID
   > #2, tableA inserts next record with OID #3, tableC then gets #4, etc...
   
   in my oo world (i.e., systems i develop), i use oid's to determine the
   type of object and due to the limitation of postgresql's oids, i use a
   separate field for the system's oid - kinda redundant but gotta live with
   it.  nonetheless, postgresql's oids can still be improved.
   
   > 	And...# of OIDs is finite...so if you have a lot of tables with
   > alot of data in each...you run the risk of running out.
   
   finitely limited :)
   
   [---]
   Neil D. Quiogue <neil@iphil.net>
   IPhil Communications Network, Inc.
   Other: neil@postgresql.org