On Mon, Aug 27, 2012 at 04:03:05PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > On Fri, Feb 17, 2012 at 02:52:20PM -0500, Robert Haas wrote: > >> 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? > > We tried that once, years ago, and it was a miserable failure: it opened > up far too many ambiguities, eg should "int4col + 1" invoke int4pl or > int42pl? (That particular case works, because there's an exact match > to int42pl, but we found an awful lot of cases where the parser couldn't > resolve a best choice. IIRC there were dozens of failures in the > regression tests then, and there would be more now.) > > There's also the problem that if "2 + 2" starts getting parsed as > smallint int2pl smallint, cases like "20000 + 20000" will overflow when > they didn't before. IMO smallint is a bit too narrow to be a useful > general-purpose integer type, so we'd end up wanting int2pl to yield > int4 to avoid unexpected overflows --- and that opens up more cans of > worms, like which version of f() gets called for f(2+2). > > 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. > > Some history: > http://archives.postgresql.org/pgsql-hackers/2002-11/msg00468.php > http://archives.postgresql.org/pgsql-hackers/2010-09/msg00223.php > (A lot of the specific details in the 2002 thread are obsolete now, > but the general point remains, I fear.)
Thanks, just asking. Odd int2 is so much harder than int8/numberic casts. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
