Re: Proposed p.tch for sequence-renaming problems
От | Alvaro Herrera |
---|---|
Тема | Re: Proposed p.tch for sequence-renaming problems |
Дата | |
Msg-id | 20050928035934.GA19804@surnet.cl обсуждение исходный текст |
Ответ на | Proposed patch for sequence-renaming problems (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Proposed p.tch for sequence-renaming problems
|
Список | pgsql-patches |
[Sorry for the subject mangling -- my outgoing MTA is too stupid] On Tue, Sep 27, 2005 at 06:46:55PM -0400, Tom Lane wrote: > Attached is a fully-worked-out patch to make SERIAL column default > expressions refer to the target sequence with a "regclass" literal > instead of a "text" literal. Since the regclass literal is actually > just an OID, it is impervious to renamings and schema changes of > the target sequence. This fixes the long-standing hazard of renaming > a serial column's sequence, as well as the recently added hazard of > renaming the schema the sequence is in; and it lets us get rid of a > very klugy solution in ALTER TABLE SET SCHEMA. Why did you rename the C function nextval() to nextval_text()? Doing this causes a compatibility problem for code using that function. I understand that it would be better for that code to be "upgraded" to call nextval_oid(), but if we can allow the code to continue to compile untouched, why not let it? (For example the change in the contrib area would be unnecessary AFAICS.) I vaguely remember there being a dependency we weren't able to track because of the sequence being a literal instead of an expression; are we able to do better now? (Of course it would be better to state what the specific problem was but I can't remember right now.) As an unrelated note, since we are going to force an initdb for the next beta, it would be nice to include the 64 bit parameter to pg_control ... -- Alvaro Herrera http://www.PlanetPostgreSQL.org "Pido que me den el Nobel por razones humanitarias" (Nicanor Parra)
В списке pgsql-patches по дате отправления: