minor bug in 7.0: casting
От | The Hermit Hacker |
---|---|
Тема | minor bug in 7.0: casting |
Дата | |
Msg-id | Pine.BSF.4.21.0002292112200.434-100000@thelab.hub.org обсуждение исходный текст |
Ответы |
Re: [HACKERS] minor bug in 7.0: casting
|
Список | pgsql-hackers |
Another one here ... ============= From: Don Baccus <dhogaza@pacifier.com> At 04:05 PM 2/29/00 -0400, you wrote: >No, bug reports are most welcome, antagonistic comments aren't ... big >difference ... donb=# create table foo(c char(2), v varchar(2)); CREATE donb=# select * from foo where c::varchar = v::varchar; ERROR: Unable to identify an operator '=' for types 'bpchar' and 'varchar' You will have to retype this query usingan explicit cast donb=# select * from foo where cast(c as varchar) = cast(v as varchar); ERROR: Unable to identify an operator '=' for types 'bpchar' and 'varchar' You will have to retype this query usingan explicit cast donb=# select * from foo where cast(c as text) = cast(v as text); ERROR: Unable to identify an operator '=' for types 'bpchar' and 'varchar' You will have to retype this query usingan explicit cast If conversion isn't going to be supported, the error message should be improved (feel free to forward this to the appropriate person). In this case, the working application actually fills both variables (in practice, from different tables) with two-character state codes, so the cast would work. Should casts presume the user doesn't know what they're doing? I don't know. I can fix this, of course, by changing the data model I've inherited from Oracle to consistently use either char(2) or varchar(2). - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net. =====================
В списке pgsql-hackers по дате отправления: