Re: Make foo=null a warning by default.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Make foo=null a warning by default.
Дата
Msg-id 23125.1531755448@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Make foo=null a warning by default.  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Make foo=null a warning by default.  (David Fetter <david@fetter.org>)
Re: Make foo=null a warning by default.  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Heikki Linnakangas <hlinnaka@iki.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: Vacuum: allow usage of more than 1GB of work mem
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Vacuum: allow usage of more than 1GB of work mem