DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ymail.com;
 h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
 b=2zQOtdKLwO1iUCrzKYOmuIKnGu5xZ5EcBCsReurhz9fwe9f12hjxErkYQdK3oM++MoIzdtjP6lGL1ncnLA6szJyepexV/C40RIgOy/J+nEtRb41CgkSwUCbhHfOTlN7KwiK+BJB3NcfPemqGOQoR5P1h87YVDDxpxo6FvOFShDY=;
References: 
 <CAK+WP1xdmyswEehMuetNztM4H199Z1w9KWRHVMKzyyFM+hV=zA@mail.gmail.com>
 <20131011194437.GA3614@momjian.us>
Message-ID: <1381525130.59803.YahooMailNeo@web162902.mail.bf1.yahoo.com>
Date: Fri, 11 Oct 2013 13:58:50 -0700 (PDT)
From: Kevin Grittner <kgrittn@ymail.com>
Reply-To: Kevin Grittner <kgrittn@ymail.com>
Subject: Re: [SQL] Comparison semantics of CHAR data type
To: Bruce Momjian <bruce@momjian.us>,
 Thomas Fanghaenel <tfanghaenel@salesforce.com>
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <20131011194437.GA3614@momjian.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Bruce Momjian <bruce@momjian.us> wrote:
> Thomas Fanghaenel wrote:

>> I was wondering about the proper semantics of CHAR comparisons in some c=
orner
>> cases that involve control characters with values that are less than 0x20
>> (space).

What matters in general isn't where the characters fall when
comparing individual bytes, but how the strings containing them
sort according to the applicable collation.=A0 That said, my
recollection of the spec is that when two CHAR(n) values are
compared, the shorter should be blank-padded before making the
comparison.=A0 *That* said, I think the general advice is to stay
away from CHAR(n) in favor or VARCHAR(n) or TEXT, and I think that
is good advice.

> I am sorry for this long email, but I would be interested to see what
> other hackers think about this issue.

Since we only have the CHAR(n) type to improve compliance with the
SQL specification, and we don't generally encourage its use, I
think we should fix any non-compliant behavior.=A0 That seems to mean
that if you take two CHAR values and compare them, it should give
the same result as comparing the same two values as VARCHAR using
the same collation with the shorter value padded with spaces.

So this is correct:

test=3D# select 'ab'::char(3) collate "en_US" < E'ab\n'::char(3) collate "e=
n_US";
=A0?column?
----------
=A0t
(1 row)

... because it matches:

test=3D# select 'ab '::varchar(3) collate "en_US" < E'ab\n'::varchar(3) col=
late "en_US";
=A0?column?
----------
=A0t
(1 row)

But this is incorrect:

test=3D# select 'ab'::char(3) collate "C" < E'ab\n'::char(3) collate "C";
=A0?column?
----------
=A0t
(1 row)

... because it doesn't match:

test=3D# select 'ab '::varchar(3) collate "C" < E'ab\n'::varchar(3) collate=
 "C";
=A0?column?
----------
=A0f
(1 row)

Of course, I have no skin in the game, because it took me about two
weeks after my first time converting a database with CHAR columns
to PostgreSQL to change them all to VARCHAR, and do that as part of
all future conversions.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers