Re: BUG #5028: CASE returns ELSE value always when type is"char"
От | Greg Stark |
---|---|
Тема | Re: BUG #5028: CASE returns ELSE value always when type is"char" |
Дата | |
Msg-id | 407d949e0909020750q40c2b695h2cf53bc86baf2a1@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #5028: CASE returns ELSE value always when type is"char" (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: BUG #5028: CASE returns ELSE value always when type is"char"
|
Список | pgsql-bugs |
On Wed, Sep 2, 2009 at 3:44 PM, Jeff Davis<pgsql@j-davis.com> wrote: > On Wed, 2009-09-02 at 08:57 -0500, Kevin Grittner wrote: >> > =A0 (a) leaving a literal as "unknown" until you've finished >> > =A0 =A0 =A0 inferring types (current behavior) >> > =A0 (b) casting every unknown to text immediately, and then trying to >> > =A0 =A0 =A0 infer the types >> >> No, that's not it. =A0I'm wondering why it isn't treated as text. >> Period. =A0Full stop. =A0Nothing to infer. =A0Anywhere that we have impl= icit >> casts defined from text to something else could, of course, still >> operate; but it would be text. =A0No guessing. > > If you have very many implicit casts, I think you lose the > predictability and safety you're looking for, and/or end up with a lot > of errors that eliminate the convenience of implicit casting. Perhaps we should stop thinking of "unknown" as, er, "unknown" and think of it as "text literal". A text literal has implicit casts to every data type but a normal text string has to be explicitly cast. Hm, that's not quite right because things like array(1)||'5' don't treat the '5' as a text literal. The "implicit cast" is preferred to treating it as text. --=20 greg http://mit.edu/~gsstark/resume.pdf
В списке pgsql-bugs по дате отправления: