Обсуждение: Re: [pgsql-advocacy] Oracle buys Innobase
Doug Quale wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: > >> On Wed, 19 Oct 2005, Richard_D_Levine@raytheon.com wrote: >> >>> I was referring to trailing blanks, but did not explicitly say it, >>> though showed it in the examples. I am pretty sure that the SQL >>> standard says that trailing whitespace is insignificant in string >>> comparison. >> >> Then we are broken too :) >> >> # select 'a ' = 'a '; >> ?column? >> ---------- >> f >> (1 row) > > # select 'a'::char(8) = 'a '::char(8); > ?column? > ---------- > t > (1 row) > > Trailing blanks aren't significant in fixed-length strings, so the > question is whether Postgresql treats comparison of varchars right. This result is being misinterpreted. select length('a'::char(8)) ==> 1 select length('a '::char(8)) ==> 1 So it isn't that the two different strings are comparing equal. The process of casting them to char(8) is trimming the blanks, so by the time they become fixed length strings, they are indeed equal. Addressing Dan's subsequent note here, I tried this in Oracle: select length(cast('a ' as varchar2(30))) from dual ==> 2 So Oracle does not trim when it casts. The subject of whether casting should trim trailing blanks is yet another tangential discussion. I would say that if the user hasn't specifically asked for a trim, it shouldn't happen, but I have not read the standard on this. We're all discussing these intricacies from a comp sci perspective. From a normal user's perspective, of course, they would prefer the DBMS to hide these types of nuances. -- Guy Rouillier
"Guy Rouillier" <guyr@masergy.com> writes: > Doug Quale wrote: >> >> # select 'a'::char(8) = 'a '::char(8); >> ?column? >> ---------- >> t >> (1 row) >> >> Trailing blanks aren't significant in fixed-length strings, so the >> question is whether Postgresql treats comparison of varchars right. > > This result is being misinterpreted. > > select length('a'::char(8)) ==> 1 > select length('a '::char(8)) ==> 1 > > So it isn't that the two different strings are comparing equal. The > process of casting them to char(8) is trimming the blanks, so by the > time they become fixed length strings, they are indeed equal. Huh??? What version of PG are you using? On 7.4.9, test=# select length('a'::char(8)); length -------- 8 (1 row) test=# select length('a '::char(8)); length -------- 8 (1 row) The truncation you describe would simply be wrong.
On Thu, 20 Oct 2005, Doug Quale wrote: > "Guy Rouillier" <guyr@masergy.com> writes: > >> Doug Quale wrote: >>> >>> # select 'a'::char(8) = 'a '::char(8); >>> ?column? >>> ---------- >>> t >>> (1 row) >>> >>> Trailing blanks aren't significant in fixed-length strings, so the >>> question is whether Postgresql treats comparison of varchars right. >> >> This result is being misinterpreted. >> >> select length('a'::char(8)) ==> 1 >> select length('a '::char(8)) ==> 1 >> >> So it isn't that the two different strings are comparing equal. The >> process of casting them to char(8) is trimming the blanks, so by the >> time they become fixed length strings, they are indeed equal. > > Huh??? What version of PG are you using? On 7.4.9, > > > test=# select length('a'::char(8)); > length > -------- > 8 > (1 row) > > test=# select length('a '::char(8)); > length > -------- > 8 > (1 row) > > The truncation you describe would simply be wrong. ams=# select length('a '::char(8)); length -------- 1 (1 row) ams=# select version(); version ---------------------------------------------------------------------- PostgreSQL 8.0.2 on i386-portbld-freebsd4.11, compiled by GCC 2.95.4 (1 row) ams=# ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
It appears that casting to a char() causes spaces to be stripped (ignored) from the string:
mls=# select length('123 '::char(8));
length
--------
3
(1 row)
mls=# select length('123 '::char(8)::varchar(8));
length
--------
3
(1 row)
but:
mls=# select length('123 '::varchar(8));
length
--------
6
(1 row)
I'm not sure about anyone else, but I would personaly consider that a bug? Should the length function return the correct length of a fixed length string, or the length of significant characters? What does the SQL standard say on this one? I googled it a bit, but didn't come up with much.
Alex Turner
NetEconomist
On 10/20/05, Marc G. Fournier <scrappy@postgresql.org> wrote:
On Thu, 20 Oct 2005, Doug Quale wrote:
> "Guy Rouillier" <guyr@masergy.com> writes:
>
>> Doug Quale wrote:
>>>
>>> # select 'a'::char(8) = 'a '::char(8);
>>> ?column?
>>> ----------
>>> t
>>> (1 row)
>>>
>>> Trailing blanks aren't significant in fixed-length strings, so the
>>> question is whether Postgresql treats comparison of varchars right.
>>
>> This result is being misinterpreted.
>>
>> select length('a'::char(8)) ==> 1
>> select length('a '::char(8)) ==> 1
>>
>> So it isn't that the two different strings are comparing equal. The
>> process of casting them to char(8) is trimming the blanks, so by the
>> time they become fixed length strings, they are indeed equal.
>
> Huh??? What version of PG are you using? On 7.4.9 ,
>
>
> test=# select length('a'::char(8));
> length
> --------
> 8
> (1 row)
>
> test=# select length('a '::char(8));
> length
> --------
> 8
> (1 row)
>
> The truncation you describe would simply be wrong.
ams=# select length('a '::char(8));
length
--------
1
(1 row)
ams=# select version();
version
----------------------------------------------------------------------
PostgreSQL 8.0.2 on i386-portbld-freebsd4.11, compiled by GCC 2.95.4
(1 row)
ams=#
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
Alex Turner <armtuk@gmail.com> writes: > It appears that casting to a char() causes spaces to be stripped (ignored) > from the string: mls=# select length('123 '::char(8)); length -------- 3 (1 row) > I'm not sure about anyone else, but I would personaly consider that a bug? No, it's a feature, as per extensive discussion some time ago when we made it do that. The general rule is that trailing spaces in a char(n) are semantically insignificant. regards, tom lane