Re: [HACKERS] SELECT BUG - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: [HACKERS] SELECT BUG
Date
Msg-id 37CF3000.27CA4B6@alumni.caltech.edu
Whole thread Raw
In response to Re: [HACKERS] SELECT BUG  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] SELECT BUG  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> On looking at the bpchar (ie, fixed-length char) comparison functions,
> I see that they *do* strip trailing blanks before comparing.  varchar
> and text do not do this --- they assume trailing blanks are real data.
> This inconsistency bothers me: I've always thought that char(),
> varchar(), and text() are functionally interchangeable, but it seems
> that's not so.  Is this behavior mandated by SQL92?

I was pretty sure it is (though of course "text" isn't an SQL92 type).
What I'm finding in Date and Darwen and my draft SQL92 document is
that whether the default character set uses SPACE PAD or NO PAD
collation attribute for a character set is implementation defined.

I haven't found any explicit reference to a distinction between CHAR
and VARCHAR in the docs nor a discussion of the SQL_TEXT character set
wrt this topic. So apparently SQL_TEXT properties are implementation
defined too. But we should look into it more before deciding to change
anything because afaik the current behavior has been the same in
Postgres forever...
                      - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
Next
From: Bruce Momjian
Date:
Subject: Re: University Masters Project