Greg Stark wrote:
>
> Kevin Brown <kevin@sysexperts.com> writes:
>
> > Hence, it makes sense to go ahead and run the query, but issue a
> > warning at the very beginning, e.g. "WARNING: query JOINs tables <list
> > of tables> without otherwise referencing or making use of those
> > tables. This may cause excessively poor performance of the query".
>
> Well the problem with a warning is what if it *is* intentional? It's
> not ok to fill my logs up with warnings for every time the query is
> executed. That just forces me to turn off warnings.
WARNING is probably the wrong level (I wasn't thinking in terms of PG
logging, though I probably should have been). What about NOTICE?
Basically, you want something that will alert the interactive user
that what they're doing is likely to be stupid, but at the same time
won't be a burden on the system or the DBA...
> It would be ok to have an option to block cartesian joins entirely. I might
> even choose to run with that enabled normally. I can always disable it for
> queries I know need cartesion joins.
Which wouldn't work all that well for people who are trying to write
their software in a reasonably portable fashion, unfortunately.
However, the number of people who care would now be much smaller.
> For that matter, I wonder whether it's time to consider an option to
> disable implicit (ie, pre-ansi join syntax) joins entirely. It seems
> like lots of shops are likely imposing coding standards that require
> ansi join syntax anyways. In environments like that you would expect
> "a CROSS JOIN b" not just "select * from a,b" anyways.
>
> Shops like that might appreciate the ability to enforce a blanket
> coding standard on that point and get protection from accidental
> cartesian joins as a side benefit.
That could be handy, but of course it should default to off, which
with respect to cross joins would unfortunately wind up benefitting
only those people who already are potentially aware of the issue and
care about it (or, at least, those people who have DBAs that care
about it).
--
Kevin Brown kevin@sysexperts.com
