Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards
В списке pgsql-hackers по дате отправления:
| От | Thomas Lockhart |
|---|---|
| Тема | Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards |
| Дата | |
| Msg-id | 3B20FCF9.A8C5505A@fourpalms.org обсуждение исходный текст |
| Ответ на | AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
| Список | pgsql-hackers |
> The way things currently work is that gram.y translates "x IS TRUE" etc
> to "x = true" etc. This is wrong because it does the wrong thing for
> null input. Another objection is that it's impossible for ruleutils.c
> to reverse-list the expression tree in its original form.
fyi, in case it helps: we used to have gram.y translate these into
function calls, rather than the operator expression. But that precluded
the optimizer from ever having a shot at optimizing out "const = const"
kinds of expressions and other fluff.
If we go to a specialized node in the parse tree, then the optimizer
could be taught to handle that, which is better than the original
straight function call which would have masked things too much.
- Thomas
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера