On 16/07/18 18:10, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>> On 16/07/18 04:40, David Fetter wrote:
>>> Per a discussion with Andrew Gierth and Vik Fearing, both of whom
>>> helped make this happen, please find attached a patch which makes it
>>> possible to get SQL standard behavior for "= NULL", which is an error.
>>> It's been upgraded to a warning, and can still be downgraded to
>>> silence (off) and MS-SQL-compatible behavior (on).
>>
>> I don't agree with changing the default to 'warn'. "foo = NULL" is
>> perfectly legal SQL, even if it's not very useful in practice.
>
> I think that there's a very narrow argument to be made that SQL doesn't
> allow a NULL literal with context-determined type in this context. But
> we decided to generalize that restriction long ago, and suddenly deciding
> to enforce it only in this one context makes no sense to me. The idea
> that we would ever decide that it's an error seems flat out ridiculous.
>
> TBH I'm not really excited about investing any work in this area at all.
> Considering how seldom we hear any questions about transform_null_equals
> anymore[1], I'm wondering if we couldn't just rip the "feature" out
> entirely.
Yeah, I was wondering about that too. But Fabien brought up a completely
new use-case for this: people learning SQL. For beginners who don't
understand the behavior of NULLs yet, I can see a warning or error being
useful training wheels. Perhaps a completely new "training_wheels=on"
option, which could check may for many other beginner errors, too, would
be better for that.
- Heikki
