Thread: weird situation, BUG or I'm not doing it right
Hello,
I found below situation weird, it seems to me a bug.
backend=> select * from valid_addr;zip_code | city_name | state_abrev
----------+----------------------+-------------00601 | ADJUNTAS | PR00602 | AGUADA |
PR00603 | AGUADILLA | PR00604 | AGUADILLA | PR00605 | AGUADILLA | PR00606 |
MARICAO | PR00610 | ANASCO | PR00611 | ANGELES | PR00612 | ARECIBO
| PR00613 | ARECIBO | PR00614 | ARECIBO | PR00616 | BAJADERO |
PR00617 | BARCELONETA | PR00622 | BOQUERON | PR00623 | CABO ROJO | PR00624 |
PENUELAS | PR00627 | CAMUY | PR00631 | CASTANER | PR00636 | ROSARIO
| PR00637 | SABANA GRANDE | PR
backend=> select * from valid_addr where state_abrev=upper('pr');zip_code | city_name | state_abrev
----------+-----------+-------------
(0 rows)
while "select * from valid_addr where state_abrev='PR';" produces following
output
zip_code | city_name | state_abrev
----------+-------------------+-------------00601 | ADJUNTAS | PR00602 | AGUADA | PR00603
|AGUADILLA | PR00604 | AGUADILLA | PR00605 | AGUADILLA | PR00606 | MARICAO |
PR00610 | ANASCO | PR00611 | ANGELES | PR00612 | ARECIBO | PR00613 | ARECIBO
| PR00614 | ARECIBO | PR00616 | BAJADERO | PR00617 | BARCELONETA | PR00622
|BOQUERON | PR00623 | CABO ROJO | PR00624 | PENUELAS | PR00627 | CAMUY |
PR00631 | CASTANER | PR00636 | ROSARIO | PR00637 | SABANA GRANDE | PR
jjw
8/24/2002
On Sat, Aug 24, 2002 at 10:56:31PM -0700, Jiaqing Wang wrote:
> Hello,
>
> I found below situation weird, it seems to me a bug.
>
> backend=> select * from valid_addr where state_abrev=upper('pr');
> zip_code | city_name | state_abrev
> ----------+-----------+-------------
> (0 rows)
>
> while "select * from valid_addr where state_abrev='PR';" produces following
> output
>
<20 lines of output>
You left out the critical piece: what's the schema for the table valid_addr?
I'll deduce that the column "state_abrev" is defined as something like
'char(4)'. It needs to be either char(2) (if _all_ state abbreviations are
guarenteed to be only 2) or as text. fixed with char fields are padded with
blanks. Not a bug, but an feature of the SQL standard.
Ross
Ross J. Reedstrom wrote:
> On Sat, Aug 24, 2002 at 10:56:31PM -0700, Jiaqing Wang wrote:
> > Hello,
> >
> > I found below situation weird, it seems to me a bug.
> >
> > backend=> select * from valid_addr where state_abrev=upper('pr');
> > zip_code | city_name | state_abrev
> > ----------+-----------+-------------
> > (0 rows)
> >
> > while "select * from valid_addr where state_abrev='PR';" produces
following
> > output
> >
> <20 lines of output>
>
> You left out the critical piece: what's the schema for the table
valid_addr?
> I'll deduce that the column "state_abrev" is defined as something like
> 'char(4)'. It needs to be either char(2) (if _all_ state abbreviations are
> guarenteed to be only 2) or as text. fixed with char fields are padded
with
> blanks. Not a bug, but an feature of the SQL standard.
>
> Ross
Then, why is 'PR' blank padded to char(?) and upper('pr') not?
It seems that when comparing char with text, the comparision is done
as text, not as bpchar.
billing=# select 'A'::char(2) = upper('a');?column?
----------f
billing=# select 'A'::char(2) = upper('a')::bpchar;?column?
----------t
Regards,
Michael Paesold
"Michael Paesold" <mpaesold@gmx.at> writes: > It seems that when comparing char with text, the comparision is done > as text, not as bpchar. Yup. Arguably this is a bad idea: the system ought to reject the comparison entirely, and make you cast one side or the other so that it's clear to all concerned which comparison semantics you want. However, I don't see any way to do that without also breaking a lot of cases that are convenient and don't confuse anyone ... like, say, the fact that you can apply upper() to char(n) data in the first place. Upper is declared as "upper(text) returns text". You might care to read the User's Guide's discussion of type conversion, http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/typeconv.html The particular behavior at hand emerges from the fact that text is considered the preferred datatype in the string category. regards, tom lane
Ross,
You're exactly right, I re-created my table with text(may not seem elegant),
the problem is solved. Thanks to all of your advice, I can now go on with my
life with PostgreSQL. :)
jjw
8/25/2002
-----Original Message-----
From: pgsql-sql-owner@postgresql.org
[mailto:pgsql-sql-owner@postgresql.org]On Behalf Of Ross J. Reedstrom
Sent: Saturday, August 24, 2002 9:28 PM
To: Jiaqing Wang
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] weird situation, BUG or I'm not doing it right
On Sat, Aug 24, 2002 at 10:56:31PM -0700, Jiaqing Wang wrote:
> Hello,
>
> I found below situation weird, it seems to me a bug.
>
> backend=> select * from valid_addr where state_abrev=upper('pr');
> zip_code | city_name | state_abrev
> ----------+-----------+-------------
> (0 rows)
>
> while "select * from valid_addr where state_abrev='PR';" produces
following
> output
>
<20 lines of output>
You left out the critical piece: what's the schema for the table valid_addr?
I'll deduce that the column "state_abrev" is defined as something like
'char(4)'. It needs to be either char(2) (if _all_ state abbreviations are
guarenteed to be only 2) or as text. fixed with char fields are padded with
blanks. Not a bug, but an feature of the SQL standard.
Ross
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org