Обсуждение: 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