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

From Marko Tiikkaja
Subject Re: Re: [PATCH] parser: optionally warn about missing AS for column and table aliases
Date
Msg-id 540A3EE1.3000608@joh.to
Whole thread Raw
In response to Re: [PATCH] parser: optionally warn about missing AS for column and table aliases  (David G Johnston <david.g.johnston@gmail.com>)
Responses Re: Re: [PATCH] parser: optionally warn about missing AS for column and table aliases  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
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.


.marko



pgsql-hackers by date:

Previous
From: David Johnston
Date:
Subject: Re: Re: [PATCH] parser: optionally warn about missing AS for column and table aliases
Next
From: Bruce Momjian
Date:
Subject: Re: Re: [BUGS] Re: BUG #9555: pg_dump for tables with inheritance recreates the table with the wrong order of columns