[DOCS] INTEGER range ("-2147483648" is not accepted.)
Hi all, I've found a bit strange thing on the INTEGER range in the official manual. http://www.postgresql.org/docs/8.4/interactive/datatype-numeric.html According to the official manual, the INTEGER range is "-2147483648 to +2147483647". However, my example in below shows that "-2147483648" is not accepted. Is this correct? Any suggestions? Regards, - template1=# SELECT version(); version PostgreSQL 8.4.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42), 32-bit (1 row) template1=# SELECT -2147483647::integer; ?column? - -2147483647 (1 row) template1=# SELECT -2147483648::integer; ERROR: integer out of range template1=# SELECT +2147483648::integer; ERROR: integer out of range template1=# SELECT +2147483647::integer; ?column? 2147483647 (1 row) template1=# - -- NAGAYASU Satoshi -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] INTEGER range ("-2147483648" is not accepted.)
2010/6/22 Satoshi Nagayasu : > Hi all, > > I've found a bit strange thing on the INTEGER range in the official manual. > > http://www.postgresql.org/docs/8.4/interactive/datatype-numeric.html > > According to the official manual, the INTEGER range is "-2147483648 to > +2147483647". > However, my example in below shows that "-2147483648" is not accepted. > > Is this correct? Any suggestions? > > Regards, > > - > template1=# SELECT version(); > version > > PostgreSQL 8.4.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 > 20071124 (Red Hat 4.1.2-42), 32-bit > (1 row) > > template1=# SELECT -2147483647::integer; > ?column? > - > -2147483647 > (1 row) > > template1=# SELECT -2147483648::integer; > ERROR: integer out of range > template1=# SELECT +2147483648::integer; > ERROR: integer out of range > template1=# SELECT +2147483647::integer; > ?column? > > 2147483647 > (1 row) > > template1=# > - > Hmm... yes, that's not what I'd expect either: postgres=# SELECT -32768::smallint; ERROR: smallint out of range postgres=# SELECT -9223372036854775808::bigint; ERROR: bigint out of range I think those min values are all out by 1. Thom -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] INTEGER range ("-2147483648" is not accepted.)
On Tue, Jun 22, 2010 at 10:27 AM, Satoshi Nagayasu wrote: > Hi all, > > I've found a bit strange thing on the INTEGER range in the official manual. > > http://www.postgresql.org/docs/8.4/interactive/datatype-numeric.html > > According to the official manual, the INTEGER range is "-2147483648 to > +2147483647". > However, my example in below shows that "-2147483648" is not accepted. > > Is this correct? Any suggestions? > > template1=# SELECT -2147483648::integer; > ERROR: integer out of range This gets parsed as "cast 2147483648 to integer, then take it negative". Which overflows, because it can only go up to 2147483647. What you want is: postgres=# select (-2147483648)::integer; int4 - -2147483648 (1 row) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] INTEGER range ("-2147483648" is not accepted.)
On 22 June 2010 09:44, Magnus Hagander wrote: > On Tue, Jun 22, 2010 at 10:27 AM, Satoshi Nagayasu > wrote: >> Hi all, >> >> I've found a bit strange thing on the INTEGER range in the official manual. >> >> http://www.postgresql.org/docs/8.4/interactive/datatype-numeric.html >> >> According to the official manual, the INTEGER range is "-2147483648 to >> +2147483647". >> However, my example in below shows that "-2147483648" is not accepted. >> >> Is this correct? Any suggestions? >> >> template1=# SELECT -2147483648::integer; >> ERROR: integer out of range > > This gets parsed as "cast 2147483648 to integer Why? And if so, it would probably be more useful if the error message was something more like: ERROR: integer 2147483648 out of range That would at least show the user what the value was seen as by the parser. Thom -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] INTEGER range ("-2147483648" is not accepted.)
On 22 June 2010 09:59, Satoshi Nagayasu wrote: > Magnus, > > Thanks for your advice. I've understood how it happens. > > However, it looks tricky and difficult to understand, > so I hope that the message could be more understandable > as Thom mentioned. > > Regards, > This does appear to be a gotcha, as the following returns a negative integer as expected: postgres=# SELECT -2147483648; ?column? - -2147483648 (1 row) postgres=# SELECT pg_typeof(-2147483648); pg_typeof --- integer (1 row) And just in case... postgres=# SELECT pg_typeof(test.my_num) FROM (SELECT -2147483648) AS test(my_num); pg_typeof --- integer (1 row) So it's affected by the cast operator? Thom -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] INTEGER range ("-2147483648" is not accepted.)
On 22 June 2010 10:46, Thom Brown wrote: > On 22 June 2010 09:59, Satoshi Nagayasu wrote: >> Magnus, >> >> Thanks for your advice. I've understood how it happens. >> >> However, it looks tricky and difficult to understand, >> so I hope that the message could be more understandable >> as Thom mentioned. >> >> Regards, >> > > This does appear to be a gotcha, as the following returns a negative > integer as expected: > > postgres=# SELECT -2147483648; > ?column? > - > -2147483648 > (1 row) > > postgres=# SELECT pg_typeof(-2147483648); > pg_typeof > --- > integer > (1 row) > > And just in case... > > postgres=# SELECT pg_typeof(test.my_num) FROM (SELECT -2147483648) AS > test(my_num); > pg_typeof > --- > integer > (1 row) > > So it's affected by the cast operator? > > Thom > Actually, come to think of it, shouldn't we have a gotchas page on the wiki? Thom -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] hot standby documentation
On Mon, Jun 21, 2010 at 11:42:03PM -0400, Robert Haas wrote: > I did some editing of the Hot Standby docs tonight; PFA a proposed patch. > > Comments? In general, +1 > +When the parameter is set to true on a > +standby server, it will begin accepting connections once the recovery has > +brought the system to a consistent state. All such connections are > +strictly read-only; not even temporary tables may be written. However, > +the database system may still use temporary work files internally when > +executing queries. I'm not sure it's worth pointing out that the database might still use temp files. It seems an unnecessary level of detail. I realize you're probably putting it here because you've edited that bit out of the docs elsewhere, but I still think it's unnecessary detail. That said, if it has to go somewhere, +1 for this change. > -Queries executed on the standby will be correct with regard to the > transactions > -that had been recovered at the start of the query, or start of first > statement > -in the case of serializable transactions. In comparison with the primary, > -the standby returns query results that could have been obtained on the > primary > -at some moment in the past. > +Queries executed on the standby will see a view of the database that > +existed on the master at some moment in the past. Is it really that non-deterministic? /me admits not having followed that discussion. Although the original version is pretty complex, it gives the user some feel for the particular moment in the past that their snapshot will represent. If the original is incorrect, it would be nice to replace it with something that doesn't suggest the user might end up with a snapshot from last week. > - If cancellation does occur, the query and/or transaction can always > - be re-executed. The error is dynamic and will not necessarily > reoccur > - if the query is executed again. > + Cancelled queries may be retried immediately (after beginning > a new > + transaction, of course). Since query cancellation is depending on > + the nature of the WAL records being replayed, a query that was > + cancelled may succeed if it is executed again. s/is depending/depends/ -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [DOCS] INTEGER range ("-2147483648" is not accepted.)
Thom, Actually, come to think of it, shouldn't we have a gotchas page on the wiki? I agree with that it should be described in some tech document, but I don't have any good idea where/how it should be written. Basically, it's a parser issue, but app developers may meet it on their type casting (my guess), and it's a bit tricky. Regards, On 2010/06/22 18:57, Thom Brown wrote: On 22 June 2010 10:46, Thom Brown wrote: On 22 June 2010 09:59, Satoshi Nagayasu wrote: Magnus, Thanks for your advice. I've understood how it happens. However, it looks tricky and difficult to understand, so I hope that the message could be more understandable as Thom mentioned. Regards, This does appear to be a gotcha, as the following returns a negative integer as expected: postgres=# SELECT -2147483648; ?column? - -2147483648 (1 row) postgres=# SELECT pg_typeof(-2147483648); pg_typeof --- integer (1 row) And just in case... postgres=# SELECT pg_typeof(test.my_num) FROM (SELECT -2147483648) AS test(my_num); pg_typeof --- integer (1 row) So it's affected by the cast operator? Thom Actually, come to think of it, shouldn't we have a gotchas page on the wiki? Thom -- NAGAYASU Satoshi -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] INTEGER range ("-2147483648" is not accepted.)
Magnus, Thanks for your advice. I've understood how it happens. However, it looks tricky and difficult to understand, so I hope that the message could be more understandable as Thom mentioned. Regards, On 2010/06/22 17:48, Thom Brown wrote: On 22 June 2010 09:44, Magnus Hagander wrote: On Tue, Jun 22, 2010 at 10:27 AM, Satoshi Nagayasu wrote: Hi all, I've found a bit strange thing on the INTEGER range in the official manual. http://www.postgresql.org/docs/8.4/interactive/datatype-numeric.html According to the official manual, the INTEGER range is "-2147483648 to +2147483647". However, my example in below shows that "-2147483648" is not accepted. Is this correct? Any suggestions? template1=# SELECT -2147483648::integer; ERROR: integer out of range This gets parsed as "cast 2147483648 to integer Why? And if so, it would probably be more useful if the error message was something more like: ERROR: integer 2147483648 out of range That would at least show the user what the value was seen as by the parser. Thom -- NAGAYASU Satoshi -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] pg_ctl server log differenes on win32
I have updated the pg_ctl docs to explain server output behavior differences on win32 and non-win32 platforms; applied patch attached. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + Index: ref/pg_ctl-ref.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/ref/pg_ctl-ref.sgml,v retrieving revision 1.50 diff -c -r1.50 pg_ctl-ref.sgml *** ref/pg_ctl-ref.sgml 8 Apr 2010 01:39:37 - 1.50 --- ref/pg_ctl-ref.sgml 22 Jun 2010 16:18:31 - *** *** 134,149 In start mode, a new server is launched. The !server is started in the background, and standard input is attached to !/dev/null. The standard output and standard !error are either appended to a log file (if the -l !option is used), or redirected to pg_ctl's !standard output (not standard error). If no log file is chosen, the !standard output of pg_ctl should be redirected !to a file or piped to another process such as a log rotating program !like rotatelogs; otherwise postgres !will write its output to the controlling terminal (from the background) !and will not leave the shell's process group. --- 134,152 In start mode, a new server is launched. The !server is started in the background, and standard input is attached !to /dev/null (or nul on Windows). !On Unix-like systems, by default, the server's standard output and !standard error are send to pg_ctl's !standard output (not standard error). The standard output of !pg_ctl should then be redirected to a !file or piped to another process such as a log rotating program !like rotatelogs; otherwise postgres !will write its output to the controlling terminal (from the !background) and will not leave the shell's process group. On !Windows, by default the server's standard output and standard error !are sent to the terminal. These default behaviors can be changed !by using -l to append server output to a log file. -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] hot standby documentation
On Tue, Jun 22, 2010 at 8:56 AM, Joshua Tolley wrote: > I'm not sure it's worth pointing out that the database might still use temp > files. It seems an unnecessary level of detail. I realize you're probably > putting it here because you've edited that bit out of the docs elsewhere, but > I still think it's unnecessary detail. That said, if it has to go somewhere, > +1 for this change. I agree, and your guess about how it ended up there is correct. Removed. >> - Queries executed on the standby will be correct with regard to the >> transactions >> - that had been recovered at the start of the query, or start of first >> statement >> - in the case of serializable transactions. In comparison with the >> primary, >> - the standby returns query results that could have been obtained on the >> primary >> - at some moment in the past. >> + Queries executed on the standby will see a view of the database that >> + existed on the master at some moment in the past. > > Is it really that non-deterministic? /me admits not having followed that > discussion. Although the original version is pretty complex, it gives the user > some feel for the particular moment in the past that their snapshot will > represent. If the original is incorrect, it would be nice to replace it with > something that doesn't suggest the user might end up with a snapshot from last > week. I had another go at this. > s/is depending/depends/ Fixed. See attached. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company hot-standby-docs-v2.patch Description: Binary data -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] hot standby documentation
On Tue, Jun 22, 2010 at 02:24:55PM -0400, Robert Haas wrote: > On Tue, Jun 22, 2010 at 8:56 AM, Joshua Tolley wrote: > >> - Queries executed on the standby will be correct with regard to the > >> transactions > >> - that had been recovered at the start of the query, or start of first > >> statement > >> - in the case of serializable transactions. In comparison with the > >> primary, > >> - the standby returns query results that could have been obtained on > >> the primary > >> - at some moment in the past. > >> + Queries executed on the standby will see a view of the database that > >> + existed on the master at some moment in the past. > > > > Is it really that non-deterministic? /me admits not having followed that > > discussion. Although the original version is pretty complex, it gives the > > user > > some feel for the particular moment in the past that their snapshot will > > represent. If the original is incorrect, it would be nice to replace it with > > something that doesn't suggest the user might end up with a snapshot from > > last > > week. > > I had another go at this. Much better, IMO. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [DOCS] INTEGER range ("-2147483648" is not accepted.)
On Tue, Jun 22, 2010 at 09:36:30AM +0100, Thom Brown wrote: > 2010/6/22 Satoshi Nagayasu : > > Hi all, > > > > I've found a bit strange thing on the INTEGER range in the official manual. > > > > http://www.postgresql.org/docs/8.4/interactive/datatype-numeric.html > > > > According to the official manual, the INTEGER range is "-2147483648 to > > +2147483647". > > However, my example in below shows that "-2147483648" is not accepted. > > > > Is this correct? Any suggestions? > > > > Regards, > > > > - > > template1=# SELECT version(); > > version > > > > PostgreSQL 8.4.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 > > 20071124 (Red Hat 4.1.2-42), 32-bit > > (1 row) > > > > template1=# SELECT -2147483647::integer; > > ?column? > > - > > -2147483647 > > (1 row) > > > > template1=# SELECT -2147483648::integer; > > ERROR: integer out of range > > template1=# SELECT +2147483648::integer; > > ERROR: integer out of range > > template1=# SELECT +2147483647::integer; > > ?column? > > > > 2147483647 > > (1 row) > > > > template1=# > > - > > > > Hmm... yes, that's not what I'd expect either: > > postgres=# SELECT -32768::smallint; > ERROR: smallint out of range > postgres=# SELECT -9223372036854775808::bigint; > ERROR: bigint out of range > > I think those min values are all out by 1. Nope. Same problem. SELECT (-32768)::smallint; -32768 SELECT (-9223372036854775808)::bigint; -9223372036854775808 I agree that the appropriate error message should complain about the actual error, which is that 32768, or 2147483648, or 9223372036854775808, as the case may be, is out of range in the positive direction. Possibly the "hint" might mention that :: binds tighter than - does. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [email protected] iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] INTEGER range ("-2147483648" is not accepted.)
On 23 June 2010 00:07, David Fetter wrote: > On Tue, Jun 22, 2010 at 09:36:30AM +0100, Thom Brown wrote: >> 2010/6/22 Satoshi Nagayasu : >> > Hi all, >> > >> > I've found a bit strange thing on the INTEGER range in the official manual. >> > >> > http://www.postgresql.org/docs/8.4/interactive/datatype-numeric.html >> > >> > According to the official manual, the INTEGER range is "-2147483648 to >> > +2147483647". >> > However, my example in below shows that "-2147483648" is not accepted. >> > >> > Is this correct? Any suggestions? >> > >> > Regards, >> > >> > - >> > template1=# SELECT version(); >> > version >> > >> > PostgreSQL 8.4.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 >> > 20071124 (Red Hat 4.1.2-42), 32-bit >> > (1 row) >> > >> > template1=# SELECT -2147483647::integer; >> > ?column? >> > - >> > -2147483647 >> > (1 row) >> > >> > template1=# SELECT -2147483648::integer; >> > ERROR: integer out of range >> > template1=# SELECT +2147483648::integer; >> > ERROR: integer out of range >> > template1=# SELECT +2147483647::integer; >> > ?column? >> > >> > 2147483647 >> > (1 row) >> > >> > template1=# >> > - >> > >> >> Hmm... yes, that's not what I'd expect either: >> >> postgres=# SELECT -32768::smallint; >> ERROR: smallint out of range >> postgres=# SELECT -9223372036854775808::bigint; >> ERROR: bigint out of range >> >> I think those min values are all out by 1. > > Nope. Same problem. > > SELECT (-32768)::smallint; > -32768 > > SELECT (-9223372036854775808)::bigint; > -9223372036854775808 > > I agree that the appropriate error message should complain about the > actual error, which is that 32768, or 2147483648, or > 9223372036854775808, as the case may be, is out of range in the > positive direction. Possibly the "hint" might mention that :: binds > tighter than - does. > Is that the right behaviour though? Shouldn't the signed value reach the cast step rather than the absolute value? Or maybe Postgres could implicitly accept -12345::integer to be (-12345)::integer. Is there a blocking reason as to why it must work this way? Am I asking too many questions? Was that last question necessary? Thom -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] INTEGER range ("-2147483648" is not accepted.)
Thom Brown writes: > Is that the right behaviour though? Shouldn't the signed value reach > the cast step rather than the absolute value? Or maybe Postgres could > implicitly accept -12345::integer to be (-12345)::integer. Is there a > blocking reason as to why it must work this way? Yes. There is no reason to assume that - means the same thing for every datatype. In general, :: should (and does) bind tighter than *every* operator, to ensure that the appropriately typed operator is applied. regards, tom lane -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
