Re: Is indexing broken for bigint columns?

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Dann Corbit
> Sent: Tuesday, February 24, 2004 4:21 PM
> To: Peter Eisentraut; PostgreSQL-development
> Subject: Re: [HACKERS] Is indexing broken for bigint columns?
>
>
> > -----Original Message-----
> > From: Peter Eisentraut [mailto:peter_e@gmx.net]
> > Sent: Tuesday, February 24, 2004 3:38 PM
> > To: Dann Corbit; PostgreSQL-development
> > Subject: Re: [HACKERS] Is indexing broken for bigint columns?
> >
> >
> > Dann Corbit wrote:
> > > http://www.phpbuilder.com/columns/smith20010821.php3?page=3
> >
> http://www.postgresql.org/docs/7.4/static/datatype.html#DATATYPE-INT

From the documentaion at the above link:

"8.1.1. Integer Types
The types smallint, integer, and bigint store whole numbers, that is,
numbers without fractional components, of various ranges. Attempts to
store values outside of the allowed range will result in an error.

The type integer is the usual choice, as it offers the best balance
between range, storage size, and performance. The smallint type is
generally only used if disk space is at a premium. The bigint type
should only be used if the integer range is not sufficient, because the
latter is definitely faster.

The bigint type may not function correctly on all platforms, since it
relies on compiler support for eight-byte integers. On a machine without
such support, bigint acts the same as integer (but still takes up eight
bytes of storage). However, we are not aware of any reasonable platform
where this is actually the case.

SQL only specifies the integer types integer (or int) and smallint. The
type bigint, and the type names int2, int4, and int8 are extensions,
which are shared with various other SQL database systems.

Note: If you have a column of type smallint or bigint with an index, you
may encounter problems getting the system to use that index. For
instance, a clause of the form

... WHERE smallint_column = 42
will not use an index, because the system assigns type integer to the
constant 42, and PostgreSQL currently cannot use an index when two
different data types are involved. A workaround is to single-quote the
constant, thus:

... WHERE smallint_column = '42'
This will cause the system to delay type resolution and will assign the
right type to the constant."

========================================================================
====================================
DRC Remark:
How deliciously ironic that it will correctly convert a character string
but not an integral type.
Am I the only person who thinks that this is totally bizarre behavior?