Re: BUG #18594: CASE WHEN ELSE failing to return the expected output when the same colum is used in WHEN and ELSE
От | Chris BSomething |
---|---|
Тема | Re: BUG #18594: CASE WHEN ELSE failing to return the expected output when the same colum is used in WHEN and ELSE |
Дата | |
Msg-id | CADrHaBFq+gK8DVpbvh-M2LVuvLu1JHz_rkKXirWCwNDZBhUUFg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18594: CASE WHEN ELSE failing to return the expected output when the same colum is used in WHEN and ELSE (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #18594: CASE WHEN ELSE failing to return the expected output when the same colum is used in WHEN and ELSE
Re: BUG #18594: CASE WHEN ELSE failing to return the expected output when the same colum is used in WHEN and ELSE |
Список | pgsql-bugs |
On Tue, 18 Feb 2025 at 10:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.
Chris
В списке pgsql-bugs по дате отправления: