Re: weird situation, BUG or I'm not doing it right
От | Michael Paesold |
---|---|
Тема | Re: weird situation, BUG or I'm not doing it right |
Дата | |
Msg-id | 002201c24c35$d5bd0ef0$0100a8c0@beeblebrox обсуждение исходный текст |
Ответ на | weird situation, BUG or I'm not doing it right (Jiaqing Wang <jjw72@swbell.net>) |
Ответы |
Re: weird situation, BUG or I'm not doing it right
|
Список | pgsql-sql |
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
В списке pgsql-sql по дате отправления: