Yeah. We document somewhere that the contents of a literal string are *not* considered while deciding what type it should be taken as; thus, the possibility of a casting failure is not part of the rules.
The length of a literal is not strictly speaking its "contents". One could for example, have its type as varchar(x) where x is its length. And then not have implicit typecasts from varchar(x) to varchar( < x).
I think such a rule would be pretty dangerous, even if we could implement it easily. As an example, if you entered something you meant as a timestamp, but you fat-fingered the punctuation or something, it'd likely fall back to being considered just "text",
I don't get that, I thought timestamps have to be preceded by "TIMESTAMP".
potentially silently changing the semantics of the expression. We had
a lot of trouble with that sort of behavior back when the system had a lot of implicit casts to text. We got rid of (most of) those in 8.3 or thereabouts, and it made the semantics generally a lot safer.
So... you solved that, it sounds like.
And yet this super dangerous behavior which could sit dormant and undiscovered in a view in a large computer system, doesn't bother anyone? OK, whatever.
From:
"David G. Johnston" Date: Subject:
Re: BUG #18594: CASE WHEN ELSE failing to return the expected output when the same colum is used in WHEN and ELSE
Есть вопросы? Напишите нам!
Соглашаюсь с условиями обработки персональных данных
✖
By continuing to browse this website, you agree to the use of cookies. Go to Privacy Policy.
