Re: Oddity with NOT IN

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Marko Tiikkaja <marko(at)joh(dot)to>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Oddity with NOT IN
Date: 2016-08-06 18:13:04
Message-ID: 010cb19c-6509-52b8-8cdf-57882d01f1b3@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8/6/16 12:57 PM, Andrew Gierth wrote:
> The easy to catch case, I think, is when the targetlist of the IN or NOT
> IN subquery contains vars of the outer query level but no vars of the
> inner one and no volatile functions. This can be checked for with a
> handful of lines in the parser or a couple of dozen lines in a plugin
> module (though one would have to invent an error code, none of the
> existing WARNING sqlstates would do).

I would still like to warn on any outer vars show up in the target list
(other than as function params), because it's still very likely to be a
bug. But I agree that what you describe is even more certain to be one.

> Maybe David Fetter's suggested module for catching missing WHERE clauses
> could be expanded into a more general SQL-'Lint' module?

Possibly, though I hadn't really considered treating this condition as
an error.

Also, there's some other common gotchas that we could better warn users
about, some of which involve DDL. One example is accidentally defining
duplicate indexes.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2016-08-06 19:48:18 Re: Parallel tuplesort (for parallel B-Tree index creation)
Previous Message Andrew Gierth 2016-08-06 18:09:52 Re: Oddity with NOT IN