Re: Re: [PATCH] parser: optionally warn about missing AS for column and table aliases - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Re: [PATCH] parser: optionally warn about missing AS for column and table aliases
Date
Msg-id CAFj8pRBZ=duo1BS7EL3Ro15n4WmRhh+HX9m8BSz0=bdQfcK1mQ@mail.gmail.com
Whole thread Raw
In response to Re: Re: [PATCH] parser: optionally warn about missing AS for column and table aliases  (Marko Tiikkaja <marko@joh.to>)
List pgsql-hackers



2014-09-06 0:53 GMT+02:00 Marko Tiikkaja <marko@joh.to>:
On 2014-09-05 11:33 PM, David G Johnston wrote:
To protect users on every query they write there would need to be some kind
of "always explain first and only execute if no warnings are thrown"
mode...and ideally some way to then override that on a per-query basis if
you know you are correct and don't want to fix the SQL...

If the static check fails the query itself would error and the detail would
contain the status result of the static analysis; otherwise the query should
return as normal.

This feels even sillier.  Instinctively, if you can contain the functionality into the EXPLAIN path only, I don't see why you couldn't do it in a single  if (..)  for every query.  I doubt you could ever measure that difference.

This at least avoids having to introduce 10 different GUC just to
accommodate this feature and neatly bundles them into named packages.

I disagree.  Even if there was such a "static analysis" mode, I think there would have to be some way of filtering some of them out.

But "10 difference GUCs" can still be avoided; see plpgsql.extra_warnings, for example.

You used a good name for these mode in other thread "defensive". We can support some  "defensive" mode.  Personally I am sure, so if somebody would to use it, it would to use it as complex. Too less granularity increase a complexity of Postgres configuration and we don't would it.

Novice mode is not correct name and can has degrading character.

In this mode people maybe got more very specific warnings (DBA doesn't like it, because logs are massive), developers should to use explicit casting much more (developers doesn't like explicit casting in SQL). But when we use a good name, then they can accept it and use it. It is paradox, so defensive mode is mainly for professionals with experience - absolute  beginner probably will hate this mode due too restrictivity
 
Regards

Pavel



.marko



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: PL/pgSQL 1.2
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: plpgsql - Assert statement