Re: String comparison and the SQL standard

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Tom Lane *EXTERN*" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: String comparison and the SQL standard
Date: 2013-01-21 15:53:54
Message-ID: A737B7A37273E048B164557ADEF4A58B0579C216@ntex2010a.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane wrote:
>> I tested not only with string literals, but also comparing
>> table columns of the respective types.
>
>> I came up with the following table of semantics used for
>> comparisons:
>
>> | CHAR(n)=CHAR(n) | VARCHAR(n)=VARCHAR(n) | CHAR(n)=VARCHAR(n) |
>> -----------+-----------------+-----------------------+--------------------+
>> Oracle | PAD SPACE | NO PAD | NO PAD |
>> -----------+-----------------+-----------------------+--------------------+
>> PostgreSQL | PAD SPACE | NO PAD | PAD SPACE |
>> -----------+-----------------+-----------------------+--------------------+
>> MySQL | PAD SPACE | PAD SPACE | PAD SPACE |
>> -----------+-----------------+-----------------------+--------------------+
>> SQL Server | PAD SPACE | PAD SPACE | PAD SPACE |
>> -----------+-----------------+-----------------------+--------------------+
>
> Interesting. Did you determine which type is assigned to an
> unmarked literal string by each system?

In Oracle it is treated like a CHAR(n):
http://docs.oracle.com/cd/E11882_01/server.112/e26088/sql_elements002.htm#SQLRF51039

"Oracle uses blank-padded comparison semantics only when
both values in the comparison are either expressions of
data type CHAR, NCHAR, text literals, or values returned
by the USER function."

I don't know about MySQL and SQL Server, but since they pad
strings with space for comparison in all cases, it probably
does not make a difference.

Yours,
Laurenz Albe

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Rich Shepard 2013-01-21 15:59:24 Re: Yet Another Timestamp Question: Time Defaults
Previous Message Adrian Klaver 2013-01-21 15:52:04 Re: Yet Another Timestamp Question: Time Defaults