Re: Re: [PATCH] parser: optionally warn about missing AS for column and table aliases

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Marko Tiikkaja <marko(at)joh(dot)to>
Cc: David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [PATCH] parser: optionally warn about missing AS for column and table aliases
Date: 2014-09-06 05:22:56
Message-ID: CAFj8pRBZ=duo1BS7EL3Ro15n4WmRhh+HX9m8BSz0=bdQfcK1mQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2014-09-06 0:53 GMT+02:00 Marko Tiikkaja <marko(at)joh(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2014-09-06 05:27:51 Re: proposal: plpgsql - Assert statement
Previous Message Pavel Stehule 2014-09-06 04:59:45 Re: PL/pgSQL 1.2