From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | David Fetter <david(at)fetter(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Make foo=null a warning by default. |
Date: | 2018-07-16 15:37:28 |
Message-ID: | 23125.1531755448@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> On 16/07/18 18:10, Tom Lane wrote:
>> 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.
Agreed --- but what we'd want that to do seems only vaguely related to
the existing behavior of transform_null_equals. As an example, we
intentionally made transform_null_equals *not* trigger on
CASE x WHEN NULL THEN ...
but a training-wheels warning for that would likely be reasonable.
For that matter, many of the old threads about this are complaining
about nulls that aren't simple literals in the first place. I wonder
whether a training-wheels feature that whined *at runtime* about null
WHERE-qual or case-test results would be more useful than a parser
check.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2018-07-16 15:47:45 | Re: Vacuum: allow usage of more than 1GB of work mem |
Previous Message | Claudio Freire | 2018-07-16 15:35:17 | Re: Vacuum: allow usage of more than 1GB of work mem |