On Thu, Nov 08, 2001 at 07:52:27AM -0700, Jason Earl wrote:
>
> Short answer, NO.
I agree. See below for my comments.
[snip]
>
> > After an INSERT the OID property is available imediately, allowing
> > code efficiency. Ironically, this same OID propery is used to get
> > the new record's PK, using an additional SQL statement, if you don't
> > use the OID as the PK.
>
> I think that depends on the language you are using to do development.
> For example, I happen to know that PyGreSQL (the Python interface I
> use) returns the oid on when you use it's insert() method, and I think
> that PHP can do this as well (it's been a while since I have done any
> PHP work). However, PostgreSQL allows you to use functions like
> nextval() and currval() to return the primary key directly (and
> inexpensively). This is what I generally do.
In my case, when there's an operation that I do very often, I write a
function that takes as arguments the values I would put in an insert,
and that function does the insert and returns the currval(nnn_seq) value.
This means you still run one query, but instead of getting an OID back,
you get the sequence value. BIG downside is you have to make one function for
each table you do inserts on this way. You obviously do that for the tables
you do inserts the most often on, or in loops.
[snip]
> > Are there any issues with restoring a database from a pg_dump file?
>
> I don't have any first hand experience with this. Perhaps someone
> else that is using oids as a primary key could chime in.
The main problem I can see is if you want to move databases between
different machines, or you want to load a backup of a database under a
different name, etc. You can/will end up with OID conflicts at some point,
while using sequences will never conflict between 2 databases on the same
machine...
>
> Jason
>
just my 1/50$
Antoine
