On Wed, Jun 23, 2010 at 10:29 AM, Mike Toews <[email protected]> wrote: > On 22 June 2010 18:49, Tom Lane <[email protected]> wrote: >> Thom Brown <[email protected]> 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 -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
