Skip site navigation (1) Skip section navigation (2)

Re: last OID and connections?

From: Adam Haberlach <adam(at)newsnipple(dot)com>
To: Johnny Jørgensen <johnny(at)halfahead(dot)dk>
Cc: pgsql-php(at)postgresql(dot)org
Subject: Re: last OID and connections?
Date: 2001-10-17 19:18:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-php
On Wed, Oct 17, 2001 at 03:27:17PM +0200, "Johnny Jørgensen" wrote:
> Once I get a current project to production state, I'm going to get a heap of users performing updates simultaneously through the same update.php, and that raises a few questions:
> 1. will pg_getlastoid() return the last oid inserted *by this user*, *on this page*, *on this connection*, or is there a possibility for them to get mixed up, because the database gets a connection from the same user (php), and reuses connections or something?

If you pass it the result object from your last insert, it should give
an oid unique to that insert.

I usually do the insert, the immediately read the row back with a select
for the pg_lastoid() in order to get the pkey.  A little wanky, but it
seems to be the way to do it.

> e.g. If a user changes his profile, and an administrator changes some other row at the same time?

If they are through seperate connections, they should be completely

> 2. I find oid's pretty clever, but are they good for unique keys? It seems, foreign key constraints won't use oid's in the current release, should i use serials instead?

Don't use them for anything persistent except for large objects.  Use
serials as primary keys.

Adam Haberlach     | Computer science has the unfortunate characteristic
adam(at)newsnipple(dot)com| that many of the pioneers of the field are still
                   | alive and doing research.
                   |        -- Adam Rifkin

In response to

pgsql-php by date

Next:From: erleDate: 2001-10-17 20:59:34
Subject: Re: Retrieving a list of tables
Previous:From: Josh BerkusDate: 2001-10-17 15:51:39
Subject: Re: last OID and connections?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group