Re: is PG able to handle a >500 GB Database?
От | Martin A. Marques |
---|---|
Тема | Re: is PG able to handle a >500 GB Database? |
Дата | |
Msg-id | 01012217310802.06366@math.unl.edu.ar обсуждение исходный текст |
Ответ на | Re: is PG able to handle a >500 GB Database? (Florent Guillaume <florent.guillaume@mail.com>) |
Ответы |
Re: is PG able to handle a >500 GB Database?
|
Список | 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 по дате отправления: