Thread: BUG #5629: ALTER SEQUENCE foo START execute a RESTART
The following bug has been logged online:
Bug reference: 5629
Logged by: Alexsander
Email address: alexsander.rosa@gmail.com
PostgreSQL version: 8.3.11
Operating system: Linux
Description: ALTER SEQUENCE foo START execute a RESTART
Details:
Steps to reproduce:
CREATE SEQUENCE foo;
SELECT setval('foo',12345);
ALTER SEQUENCE foo START WITH 10; -- can't change value
SELECT nextval('foo'); -- it's 10 instead of 12346
Apparently START is executing a RESTART.
"Alexsander" <alexsander.rosa@gmail.com> writes:
> CREATE SEQUENCE foo;
> SELECT setval('foo',12345);
> ALTER SEQUENCE foo START WITH 10; -- can't change value
> SELECT nextval('foo'); -- it's 10 instead of 12346
> Apparently START is executing a RESTART.
Yup. That's what it's defined to do, pre-8.4.
regards, tom lane
Then the docs are misleading: http://www.postgresql.org/docs/8.3/static/sql-altersequence.html According the docs, 8.3 does NOT have a START clause -- only RESTART. I think a START clause should raise an error at 8.3 servers; there's a chance of someone run the command in several servers (like a pgdiff) and get different behaviour for the same command. 2010/8/26 Tom Lane <tgl@sss.pgh.pa.us> > "Alexsander" <alexsander.rosa@gmail.com> writes: > > CREATE SEQUENCE foo; > > SELECT setval('foo',12345); > > ALTER SEQUENCE foo START WITH 10; -- can't change value > > SELECT nextval('foo'); -- it's 10 instead of 12346 > > > Apparently START is executing a RESTART. > > Yup. That's what it's defined to do, pre-8.4. > > regards, tom lane > --=20 Atenciosamente, Alexsander da Rosa Linux User #113925 "Extremismo na defesa da liberdade n=E3o =E9 defeito. Modera=E7=E3o na busca por justi=E7a n=E3o =E9 virtude." -- Barry Goldwater
Alexsander Rosa <alexsander.rosa@gmail.com> writes:
> According the docs, 8.3 does NOT have a START clause -- only RESTART. I
> think a START clause should raise an error at 8.3 servers; there's a chance
> of someone run the command in several servers (like a pgdiff) and get
> different behaviour for the same command.
We're not going to change the behavior like that in stable branches...
regards, tom lane
On 2010-08-27 12:51 AM +0300, Tom Lane wrote: > Alexsander Rosa<alexsander.rosa@gmail.com> writes: >> According the docs, 8.3 does NOT have a START clause -- only RESTART. I >> think a START clause should raise an error at 8.3 servers; there's a chance >> of someone run the command in several servers (like a pgdiff) and get >> different behaviour for the same command. > > We're not going to change the behavior like that in stable branches... How about documenting it? Regards, Marko Tiikkaja
---------- Forwarded message ---------- From: Alexsander Rosa <alexsander.rosa@gmail.com> Date: 2010/8/27 Subject: Re: [BUGS] BUG #5629: ALTER SEQUENCE foo START execute a RESTART To: Tom Lane <tgl@sss.pgh.pa.us> Let me get this straight: in version 8.3 the ALTER SEQUENCE command has an *undocumented* [1] clause START that is actually an alias for RESTART (i.e. both reset the sequence value to the value passed by the mandatory argument). In version 8.4 this behavior was *changed* and, according the docs [2], START now changes the "default start value" that will be used by subsequent calls of ALTER SEQUENCE ... RESTART without argument (which is not mandatory anymore). Is this correct? Is the 8.3 behavior of ALTER SEQUENCE ... START clause as an alias to RESTART a known bug (or unintended feature) than cannot be corrected because it's a stable branch? Who would be using an undocumented buggy clause, anyway? If it's not being considered a bug, or if it's not going to be fixed, I think the docs should at least mention this oddity. [1] http://www.postgresql.org/docs/8.3/static/sql-altersequence.html [2] http://www.postgresql.org/docs/8.4/static/sql-altersequence.html 2010/8/26 Tom Lane <tgl@sss.pgh.pa.us> > Alexsander Rosa <alexsander.rosa@gmail.com> writes: > > > According the docs, 8.3 does NOT have a START clause -- only RESTART. I > > think a START clause should raise an error at 8.3 servers; there's a > chance > > of someone run the command in several servers (like a pgdiff) and get > > different behaviour for the same command. > > We're not going to change the behavior like that in stable branches... > > regards, tom lane > --=20 Atenciosamente, Alexsander da Rosa Linux User #113925 "Extremismo na defesa da liberdade n=E3o =E9 defeito. Modera=E7=E3o na busca por justi=E7a n=E3o =E9 virtude." -- Barry Goldwater --=20 Atenciosamente, Alexsander da Rosa Linux User #113925 "Extremismo na defesa da liberdade n=E3o =E9 defeito. Modera=E7=E3o na busca por justi=E7a n=E3o =E9 virtude." -- Barry Goldwater
Alexsander Rosa <alexsander.rosa@gmail.com> writes:
> Let me get this straight: in version 8.3 the ALTER SEQUENCE command has an
> *undocumented* [1] clause START that is actually an alias for RESTART (i.e.
> both reset the sequence value to the value passed by the mandatory
> argument).
Yeah. I just looked at the old code a bit. This behavior was an
artifact of a sloppy implementation: internally, CREATE SEQUENCE ...
START WITH x did the same thing as ALTER SEQUENCE ... RESTART WITH x, so
the code didn't prevent you from using either spelling in either place.
But it wasn't documented or intended that you should write CREATE
SEQUENCE RESTART or ALTER SEQUENCE START.
As of 8.4 ALTER SEQUENCE START has an actually designed meaning, which
is different from ALTER SEQUENCE RESTART. This wasn't documented as an
incompatibility because the syntax wasn't supposed to exist at all
before that.
I'm not inclined to go and retroactively document that these spellings
are possible but deprecated in the old branches. I think that would
just confuse matters even more.
regards, tom lane
Tom Lane escreveu: > I'm not inclined to go and retroactively document that these spellings > are possible but deprecated in the old branches. I think that would > just confuse matters even more. > Is it worth preventing that sloppy implementation in the old branches? -- Euler Taveira de Oliveira http://www.timbira.com/
Excerpts from Euler Taveira de Oliveira's message of mié sep 01 10:18:10 -0400 2010: > Tom Lane escreveu: > > I'm not inclined to go and retroactively document that these spellings > > are possible but deprecated in the old branches. I think that would > > just confuse matters even more. > > Is it worth preventing that sloppy implementation in the old branches? That risks removing a (mis)feature that people are currently depending on. -- Ãlvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
What about the risk of using ALTER SEQUENCE ... START N in a mixed environment? In the 8.4.x servers it will work as designed but in the 8.3.x (and below) servers, instead of issuing an error it will CORRUPT the sequence value without notice. I understand the point of keeping a (mis)feature when it's harmless or at least not amibiguous, but this is not the case here. While the 8.4 behavior -- the correct one -- is a mere configuration of little consequence, the 8.3 (and below) behavior is an unexpected RESET. I think it's safer to require the people that was using old versions with the wrong spell to fix their code than put lots of users of the current version in risk of using a potentially disastrous command -- when executed in previous versions. Should all 8.4.x (and beyond) users be forced to check server version before issuing this command? 2010/9/1 Alvaro Herrera <alvherre@commandprompt.com> > Excerpts from Euler Taveira de Oliveira's message of mi=E9 sep 01 10:18:10 > -0400 2010: > > Tom Lane escreveu: > > > I'm not inclined to go and retroactively document that these spellings > > > are possible but deprecated in the old branches. I think that would > > > just confuse matters even more. > > > > Is it worth preventing that sloppy implementation in the old branches? > > That risks removing a (mis)feature that people are currently depending on. > > -- > =C1lvaro Herrera <alvherre@commandprompt.com> > The PostgreSQL Company - Command Prompt, Inc. > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > --=20 Atenciosamente, Alexsander da Rosa Linux User #113925 "Extremismo na defesa da liberdade n=E3o =E9 defeito. Modera=E7=E3o na busca por justi=E7a n=E3o =E9 virtude." -- Barry Goldwater
Alexsander Rosa wrote: > What about the risk of using ALTER SEQUENCE ... START N in a mixed > environment? In the 8.4.x servers it will work as designed but in the 8.3.x > (and below) servers, instead of issuing an error it will CORRUPT the > sequence value without notice. I understand the point of keeping a > (mis)feature when it's harmless or at least not amibiguous, but this is not > the case here. While the 8.4 behavior -- the correct one -- is a mere > configuration of little consequence, the 8.3 (and below) behavior is an > unexpected RESET. I think it's safer to require the people that was using > old versions with the wrong spell to fix their code than put lots of users > of the current version in risk of using a potentially disastrous command -- > when executed in previous versions. Should all 8.4.x (and beyond) users be > forced to check server version before issuing this command? Should all 8.3 users be required to retest their applications after a minor upgrade? No. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Well, if it's not going to be fixed, then at least the docs should be revised to warn all 8.4+ users to avoid this command and, if it's really needed, always check the server version before using the ALTER SEQUENCE ... START command, once it has a potentially hazardous bug that interprets it as a RESTART in 8.3 version and below. 2010/9/7 Bruce Momjian <bruce@momjian.us> > Alexsander Rosa wrote: > > What about the risk of using ALTER SEQUENCE ... START N in a mixed > > environment? In the 8.4.x servers it will work as designed but in the > 8.3.x > > (and below) servers, instead of issuing an error it will CORRUPT the > > sequence value without notice. I understand the point of keeping a > > (mis)feature when it's harmless or at least not amibiguous, but this is > not > > the case here. While the 8.4 behavior -- the correct one -- is a mere > > configuration of little consequence, the 8.3 (and below) behavior is an > > unexpected RESET. I think it's safer to require the people that was usi= ng > > old versions with the wrong spell to fix their code than put lots of > users > > of the current version in risk of using a potentially disastrous command > -- > > when executed in previous versions. Should all 8.4.x (and beyond) users > be > > forced to check server version before issuing this command? > > Should all 8.3 users be required to retest their applications after a > minor upgrade? No. > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + > --=20 Atenciosamente, Alexsander da Rosa Linux User #113925 "Extremismo na defesa da liberdade n=E3o =E9 defeito. Modera=E7=E3o na busca por justi=E7a n=E3o =E9 virtude." -- Barry Goldwater