From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Greg Sabino Mullane <greg(at)turnstep(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: MySQL search query is not executing in Postgres DB |
Date: | 2012-08-28 17:40:28 |
Message-ID: | 503D028C.2070409@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8/27/12 5:19 PM, Greg Sabino Mullane wrote:
> Tom Lane replied:
>>>> >>>Come on, really? Note that the above example works without casts if
>>>> >>>you use int*or* bigint*or* numeric, but not smallint. That could be
>>>> >>>fixed by causing sufficiently-small integers to lex as smallints,
>>> >>Is there any general interest in adjusting smallint casting?
> ...
>> >It's conceivable that a change in the lexer behavior combined with a
>> >massive reorganization of the integer-related operators would bring us
>> >to a nicer place than where we are now. But it'd be a lot of work for
>> >dubious reward, and it would almost certainly generate a pile of
>> >application compatibility problems.
> Okay, but what about a more targeted solution to the original
> poster's problem? That seems doable without causing major
> breakage elsewhere....
FWIW, this causes problems for me at work as well.
For the case of
const op const
instead of trying to small-cast the 2 constants, would it be possible to large-cast them, perform the operation, and then re-cast the results of the operation? ISTM that would solve the operator issue (ie, the case of 20000+20000).
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-08-28 17:51:26 | Re: "default deny" for roles |
Previous Message | Tom Lane | 2012-08-28 17:39:42 | Re: MySQL search query is not executing in Postgres DB |