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.
Am I understanding correctly that this would be looking for bogus conditions in the plan tree? Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
