Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards
От | Tom Lane |
---|---|
Тема | Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards |
Дата | |
Msg-id | 9756.992013945@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards ("Joe Conway" <joe@conway-family.com>) |
Список | pgsql-hackers |
"Joe Conway" <joe@conway-family.com> writes: >> We do not currently have correct implementations of IS TRUE, IS FALSE, >> or IS UNKNOWN (IS TRUE/FALSE are in there but give the wrong result >> for null inputs). This is on my to-do list to fix; not sure if the >> master TODO list mentions it or not. Actually it'd be a good project >> for a newbie hacker who wants to learn about the backend's >> expression-handling machinery. Anyone want to take it on? > I'd like to finish up the has_table_privilege function over the next week or > so and then take this on. Can you point me in a direction to start looking? 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. IS [NOT] NULL is handled a little differently: gram.y generates a specialized Expr node, which parse_expr.c translates to a function call on the specialized functions nullvalue() and nonnullvalue() respectively. I don't much care for this implementation either, again partly because ruleutils.c has to be uglified to deal with it, but partly because the optimizer can't cheaply recognize IS NULL tests either. I'd like to see all eight of these guys translated into a specialized kind of expression node, called perhaps BooleanTest. Actually, it'd probably be wise to keep IS NULL separate from the six boolean tests, with an eye to the future when it will need to support nonscalar arguments. So maybe BooleanTest and NullTest node types, each with a field showing exactly which test is wanted. Adding a new expression node type is a straightforward but rather tedious exercise in teaching some dozens of places what to do with it. A grep for existing expression node types, such as CaseExpr or FieldSelect or RelabelType, will give you a good idea what needs to be done. regards, tom lane
В списке pgsql-hackers по дате отправления: