> On Mon, Nov 26, 2018 at 9:19 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Tue, Aug 7, 2018 at 11:19 PM Bruce Momjian <br...@momjian.us> wrote: > > > > On Mon, Jul 16, 2018 at 11:37:28AM -0400, Tom Lane wrote: > > > Heikki Linnakangas <hlinn...@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. > > > > I will again say I would love to see this as part of a wholesale > > "novice" mode which warns of generally bad SQL practices. I don't see > > this one item alone as sufficiently useful. > > Valid point. Maybe then at least we can outline what kind of bad SQL practices > could be included into this "novice mode" to make it sufficiently useful? > Otherwise this sounds like a boundless problem.
Due to lack of response I'm marking this as returned with feedback. Of course feel free to resubmit it.
