pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedRe: [pgsql-advocacy] Oracle buys Innobase
5+ messages / 5 participants
[nested] [flat]
* Re: [pgsql-advocacy] Oracle buys Innobase
@ 2005-10-19 21:07 Guy Rouillier <guyr@masergy.com>
2005-10-20 20:29 ` Re: [pgsql-advocacy] Oracle buys Innobase Doug Quale <quale1@charter.net>
0 siblings, 1 reply; 5+ messages in thread
From: Guy Rouillier @ 2005-10-19 21:07 UTC (permalink / raw)
To: pgsql-general@postgresql.org
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [pgsql-advocacy] Oracle buys Innobase
2005-10-19 21:07 Re: [pgsql-advocacy] Oracle buys Innobase Guy Rouillier <guyr@masergy.com>
@ 2005-10-20 20:29 ` Doug Quale <quale1@charter.net>
2005-10-21 00:45 ` Re: [pgsql-advocacy] Oracle buys Innobase Marc G. Fournier <scrappy@postgresql.org>
0 siblings, 1 reply; 5+ messages in thread
From: Doug Quale @ 2005-10-20 20:29 UTC (permalink / raw)
To: pgsql-general@postgresql.org
"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.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [pgsql-advocacy] Oracle buys Innobase
2005-10-19 21:07 Re: [pgsql-advocacy] Oracle buys Innobase Guy Rouillier <guyr@masergy.com>
2005-10-20 20:29 ` Re: [pgsql-advocacy] Oracle buys Innobase Doug Quale <quale1@charter.net>
@ 2005-10-21 00:45 ` Marc G. Fournier <scrappy@postgresql.org>
2005-10-21 14:16 ` Re: [pgsql-advocacy] Oracle buys Innobase Alex Turner <armtuk@gmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Marc G. Fournier @ 2005-10-21 00:45 UTC (permalink / raw)
To: Doug Quale <quale1@charter.net>; +Cc: pgsql-general@postgresql.org
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [pgsql-advocacy] Oracle buys Innobase
2005-10-19 21:07 Re: [pgsql-advocacy] Oracle buys Innobase Guy Rouillier <guyr@masergy.com>
2005-10-20 20:29 ` Re: [pgsql-advocacy] Oracle buys Innobase Doug Quale <quale1@charter.net>
2005-10-21 00:45 ` Re: [pgsql-advocacy] Oracle buys Innobase Marc G. Fournier <scrappy@postgresql.org>
@ 2005-10-21 14:16 ` Alex Turner <armtuk@gmail.com>
2005-10-21 16:47 ` Re: [pgsql-advocacy] Oracle buys Innobase Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 5+ messages in thread
From: Alex Turner @ 2005-10-21 14:16 UTC (permalink / raw)
To: Marc G. Fournier <scrappy@postgresql.org>; +Cc: Doug Quale <quale1@charter.net>; pgsql-general@postgresql.org
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
>
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [pgsql-advocacy] Oracle buys Innobase
2005-10-19 21:07 Re: [pgsql-advocacy] Oracle buys Innobase Guy Rouillier <guyr@masergy.com>
2005-10-20 20:29 ` Re: [pgsql-advocacy] Oracle buys Innobase Doug Quale <quale1@charter.net>
2005-10-21 00:45 ` Re: [pgsql-advocacy] Oracle buys Innobase Marc G. Fournier <scrappy@postgresql.org>
2005-10-21 14:16 ` Re: [pgsql-advocacy] Oracle buys Innobase Alex Turner <armtuk@gmail.com>
@ 2005-10-21 16:47 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 5+ messages in thread
From: Tom Lane @ 2005-10-21 16:47 UTC (permalink / raw)
To: Alex Turner <armtuk@gmail.com>; +Cc: Marc G. Fournier <scrappy@postgresql.org>; Doug Quale <quale1@charter.net>; pgsql-general@postgresql.org
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
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2005-10-21 16:47 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-10-19 21:07 Re: [pgsql-advocacy] Oracle buys Innobase Guy Rouillier <guyr@masergy.com>
2005-10-20 20:29 ` Doug Quale <quale1@charter.net>
2005-10-21 00:45 ` Marc G. Fournier <scrappy@postgresql.org>
2005-10-21 14:16 ` Alex Turner <armtuk@gmail.com>
2005-10-21 16:47 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox