Re: INTEGER range ("-2147483648" is not accepted.)
От | Robert Haas |
---|---|
Тема | Re: INTEGER range ("-2147483648" is not accepted.) |
Дата | |
Msg-id | AANLkTimeeHeJFKVPiBtcnwiH05OVPhSgpCYT2xrtV35v@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INTEGER range ("-2147483648" is not accepted.) (Mike Toews <mwtoews@gmail.com>) |
Список | pgsql-docs |
On Wed, Jun 23, 2010 at 10:29 AM, Mike Toews <mwtoews@gmail.com> wrote: > On 22 June 2010 18:49, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Thom Brown <thombrown@gmail.com> 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. >> > > Sorry for adding to the non-DOC drift, but why is - assumed to be a > unary operator on an unsigned integer, rather than parsed as part of > an integer? Integers have digits with an optional - or + prefix (not > unary operators). E.g., ([+\-]?[0-9]+) You can't assume that a dash followed by digits is always a negative number. Consider: SELECT 10-4; If you we interpret this as "10" followed by "-4", it's a syntax error. You have to treat it as a separate token and work out later whether it's a binary operator or a prefix operator. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-docs по дате отправления: