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

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Re: [PATCH] parser: optionally warn about missing AS for column and table aliases
Дата
Msg-id CAFj8pRBZ=duo1BS7EL3Ro15n4WmRhh+HX9m8BSz0=bdQfcK1mQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: [PATCH] parser: optionally warn about missing AS for column and table aliases  (Marko Tiikkaja <marko@joh.to>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: PL/pgSQL 1.2
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: plpgsql - Assert statement