Re: is PG able to handle a >500 GB Database? - Mailing list pgsql-general

From Martin A. Marques
Subject Re: is PG able to handle a >500 GB Database?
Date
Msg-id 01012217310802.06366@math.unl.edu.ar
Whole thread Raw
In response to Re: is PG able to handle a >500 GB Database?  (Florent Guillaume <florent.guillaume@mail.com>)
Responses Re: is PG able to handle a >500 GB Database?  (Florent Guillaume <efgeor@noos.fr>)
List pgsql-general
Sorry if I missed something.

El Vie 19 Ene 2001 11:08, Florent Guillaume escribió:
> > Unless your application logic tries to use OIDs as row identifiers,
> > duplicate OIDs in user tables are not a problem.
>
> Hmmm, that means that the following, which I use, is not strictly correct :
>
> create table t1 (recordid SERIAL PRIMARY KEY, val INT4, name TEXT);
> ... much later ...
> insert into t1 (val, name) values (3465, 'blah');
> -- PHP application gets $lastoid for this insert

pg_getlastoid?

> select recordid from t1 where oid = $lastoid;
> -- PHP application now hast the recordid that was created.
>
> Because the last select could return several lines.

Shouldn't! oids are unique over the whole database server (I'm right on
this?) So you should have only one or non.

> What would be the correct idiom ? Explicitly use nextval ? That pretty
> defeats the point of SERIAL, no ?

SERIAL in Postgres is a primary key + a sequence + a default value on the
column to nextval. Pretty different from informix.

Saludos... :-)

--
System Administration: It's a dirty job,
but someone told I had to do it.
-----------------------------------------------------------------
Martín Marqués            email:     martin@math.unl.edu.ar
Santa Fe - Argentina        http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------

pgsql-general by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Arrays advanced usage
Next
From: Peter Eisentraut
Date:
Subject: Re: RE: couple of general questions