Всем привет! Забаунтил вопрос на SO, которому 5 лет и на

который не было ИМХО правильного ответа: https://stackoverflow.com/questions/38638890/prevent-evaluation-of-non-matching-case/67814775?noredirect=1#comment119972264_67814775
Свой ответ получил на:

SELECT
current_catalog
,current_catalog::text = 'test'
,CASE
WHEN current_catalog::text = 'test' THEN 1 -- division by zero
-- WHEN true THEN 1 -- that's OK
ELSE 1/0
END
почему division by zero возникает, даже когда ELSE не должен выполняться

Но может он неправильный?
Покритикуйте плиз

> почему division by zero возникает, даже когда ELSE не должен выполняться Строго говоря, потому, что "не должен выполняться" — это просто (неправильная) надежда, не более того. Остальное — детали реализации. Т.е., насколько я помню, любой SQL-сервер (по стандарту ISO) может выполнять части CASE в произвольном порядке, если это в принципе возможно для данного CASE и не меняет результат, игнорируя при этом возможность ошибок (как и любые части любого запроса при том же условии — это общий принцип работы SQL).

Я абсолютно с Вами согласен, что предикаты WHEN могут выполняться в любом порядке Но не ELSE - ELSE может исполняться только после проверки всех предикатов Другое дело, то что в конкретном случае ELSE 1/0 - постгрес выполняет "оптимизацию" 1/0 до запроса И любопытно, что: SELECT CASE WHEN true THEN 1 ELSE 1/0 END выполняется как ожидаемо на PostgreSQL 10.0 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18), 64-bit `WHEN true `перебивает ELSE Т.е. это больше относится к internals постгреса Не знаю как Вам, мне это показалось любопытным https://www.db-fiddle.com/f/4jyoMCicNSZpjMt4jFYoz5/1737

> Но не ELSE - ELSE может исполняться только после проверки всех предикатов Ещё раз — нет, Вы неправы. Он может и будет выполняться в том порядке, в каком "захочет" реализация SQL. Вы зря думаете, что в других реализациях SQL нет такого же поведения, между прочим. И да, лично я считаю, что если конкретный человек этого не знает, то SQL он на "нормальном" уровне не владеет пока — потому что он будет писать на первый взгляд корректные запросы, которые работают ровно до тех пор, пока данная реализация SQL не "воспользуется своим правом" переупорядочивания вычислений. Т.е. такой человек время от времени будет "закладывать мины" в продукт / программу / что он там пишет. ;( > Не знаю как Вам, мне это показалось любопытным Совершенно нет. ;) Более того, это подробно описано в документации. См. note в конце https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-CASE и по ссылкам.

I don't know where you get the idea that ELSE could be executed before checking conditions from this: CASE clauses can be used wherever an expression is valid. Each condition is an expression that returns a boolean result. If the condition's result is true, the value of the CASE expression is the result that follows the condition, and the remainder of the CASE expression is not processed. If the condition's result is not true, any subsequent WHEN clauses are examined in the same manner. If no WHEN condition yields true, the value of the CASE expression is the result of the ELSE clause. If the ELSE clause is omitted and no condition is true, the result is null. It's clearly stated : "If no WHEN condition yields true, the value of the CASE expression is the result of the ELSE clause" Actually postgres documentation states even more: "the remainder of the CASE expression is not processed". So they decided to implement more "linear" logic, more understandable to "usual "programmers And about ELSE: ELSE itself has no condition, so there is nothing to evaluate. In order or out of order. It's always last after all checks

I get it straight out of ISO SQL. Just as the general idea I stated above, you know. > It's clearly stated And I've clearly stated: read the note, this one: As described in Section 4.2.14, there are various situations in which subexpressions of an expression are evaluated at different times, so that the principle that “CASE evaluates only necessary subexpressions” is not ironclad. For example a constant 1/0 subexpression will usually result in a division-by-zero failure at planning time, even if it's within a CASE arm that would never be entered at run time. then read the link in this note (you'll find even more "exiting" examples there). Do you really expect me to spoon-feed you? ;)

aha Now we are going to ISO SQL. Because for postgresql there is a clear statement: This is similar to the switch statement in C. And C impementations differs a lot but I never heard about the one that randomizes or paralleliizes switch statements. (Just checked if OpenMP does something like that - it's not )

Confess, don't be shy — you didn't read neither the note, nor the link, did you? ;) And why are you answering in English, BTW? ;) Jokes aside: > Now we are going to ISO SQL. Sure we do. That's a general principle, it might work like this in any SQL RDBMS (did you miss this part before?), and does work like this in quite a few ones, in practice. And, just to clarify — I'm not arguing with you, I'm explaining. Sure, I'm no authority to you, but your real choice is either listen to what I say and learn, or ignore it and stay not-so-competent, or RTFM (and/or read ISO SQL and understand it from there).

hm. You did not provide link - so I don't even know which ISO specification you're citing But anyway - why ISO SQL? Let's go directly to giants - Hoare or Dijkstra or IDK who would be more appropriate in your opinion English - I found it's better suited in situations like this. It makes people to think twice before they write or speak something unrelated to theme. Clarification: I know that you're a knowledgeable member of this community. Your clarifications about dumps helped me in past But right now it looks for me as: "I said that, I understand that I said something wrong but anyway I will continue because ... " IDK for what reasons And please stop assumptions about "knowledge of SQL" or some "general principles" and so on

/report Уважаемые модераторы, это просто вопрос — что Вы скажете по поводу такой позиции: "English - I found it's better suited in situations like this. It makes people to think twice before they write or speak something unrelated to theme." Разрешено / стоит ли в чате общаться на английском вообще (и особенно в данном случае, когда для всех участников темы русский язык, как мне кажется, родной)?

Ну если совсем неприемлемо - то извините, больше не буду

Описание: Чат русскоязычного сообщества PostgreSQL, здесь мы обсуждаем технические вопросы

Я хочу узнать, что думают модераторы, чтобы продолжить на соответствующем языке. В любом случае, мы тут не одни, и мне кажется, что писать на не родном для участников языке не очень красиво. Да и вообще сама ситуация, когда русскоязычные люди общаются на английском в русскоязычном чате, мне кажется какой-то сюрреальной. ;)

Ярослав, Вы тут более давний член сообщества Могли бы меня одернуть после первого же сообщения

> Ярослав, Вы тут более давний член сообщества > Могли бы меня одернуть после первого же сообщения Ну и что (в правилах-то явно не написано)? И вообще, я был несколько, мягко говоря, поражён таким поворотом. ;) Ладно, продолжим на более адекватном языке. > You did not provide link - so I don't even know which ISO specification you're citing "Link" был не про спецификацию, а про link, который есть в той note в документации PostgreSQL, а ведёт он сюда: https://www.postgresql.org/docs/current/sql-expressions.html#SYNTAX-EXPRESS-EVAL > But anyway - why ISO SQL? Потому что при реализации т.н. RDBMS разработчики обычно смотрят именно на него, а не на гигантов вроде Дейкстры, или Хоара... или Дарвина. ;) > But right now it looks for me as: "I said that, I understand that I said something wrong but anyway I will continue because ... " IDK for what reasons Я ничего неправильного не написал. Поэтому прекратите попытки приписывать мне те чувства, которые у меня нет никаких реальных причин испытывать. ;) > And please stop assumptions about "knowledge of SQL" or some "general principles" and so on С чего бы? Я объяснил, почему лично я считаю незнание этого общего принципа (для всех "реляционных" СУБД) признаком недостаточного владения SQL. А что Вам насчёт этого общего принципа принципа не нравится, я как-то не понял. Он описан (в любой версии, насколько я помню) ISO SQL. Как я уже писал — хотите его найти, почитайте стандарт самостоятельно (но предупреждаю — из него Вы почти наверняка мало что поймёте просто потому, что описания там [крайне] сложны и туманны).

Так можно дойти и до того, что ссылки на англоязычные ресурсы будут под вопросом - а вдруг не поймут?

Тем не менее, "вообще сама ситуация, когда русскоязычные люди общаются на английском в русскоязычном чате, мне кажется какой-то сюрреальной".

+1

🤷‍♂️ владение английским - это скорее плюс 😉

плюс, да. но я сюда хожу именно для того, чтобы говорить по-русски на интересную мне тему.

I'm living in нуёрк уже как three weeks и просто как это po-russki...

Но упражняться лучше в других местах. Не все умеют бегло читать и воспринимать информацию на иностранном языке.

... О да, — возразил молодой сей господин. — Я есть большой замерзавец на свой хрупкий организм». — Послушай, — робко возразила жена, — разве есть такое слово «замерзавец»? — Ну да. Человек, который быстро замерзает, суть замерзавец. Пишу дальше: ... Ну и т.д. Ладно, это off topic. ;)

Да нормально по-моему. Ну да, теоретически перевести мысль на русский можно -- но практически будет много отличий. Так что что тут такого. Опять жэ, про конкретный случай: если человек дажэ не понимает письменный технический английский -- то ваша дискуссия будет всё равно сильно за пределами его понятий.

Ваше право. Вопрос в том, что если кто-то спросит по-английски по теме, кто-то ответит по-английски по теме, это на что-то повлияет?

нет, но лучше ОЧЕНЬ хорошо знать этому меру

если один из них говорит на английском и не знает русский — в порядке вещей. если оба говорят по-русски — дикость в этом конкретном чате. моё мнение