Re: plpgsql.warn_shadow

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: plpgsql.warn_shadow
Дата
Msg-id CAFj8pRD9BtYX31Lq6Hbx3K1M=dqMc9n886QZTEw164GQEZC-aQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: plpgsql.warn_shadow  (Marko Tiikkaja <marko@joh.to>)
Ответы Re: plpgsql.warn_shadow  (Marko Tiikkaja <marko@joh.to>)
Список pgsql-hackers



2014/1/15 Marko Tiikkaja <marko@joh.to>
On 1/15/14 2:27 PM, Pavel Stehule wrote:
2014/1/15 Marko Tiikkaja <marko@joh.to>
Yeah, me neither, it's just something that needs to be communicated very
clearly.  So probably just a list  plpgsql.warnings  would be the most
appropriate then.


I am thinking so the name is not good. Changing handling warnings is messy
- minimally in Postgres, where warnings and errors are different creatures.

what about

plpgsql.enhanced_checks = (none | warning | error)

You crammed several suggestions into one here:

  1) You're advocating the ability to turn warnings into errors.  This has been met with some resistance.  I think it's a useful feature, but I would be happy with just having warnings available.
  2) This syntax doesn't allow the user to specify a list of warnings to enable.  Which might be fine, I guess.  I imagine the normal approach would be to turn all warnings on anyway, and possibly fine-tune with per-function directives if some functions do dangerous things on purpose.
  3) You want to change the name to "enhanced_checks".  I still think the main feature is about displaying warnings to the user.  I don't particularly like this suggestion.

You first should to say, what is warning and why it is only warning and not error. And why plpgsql warning processing should be different than general postgresql processing?

My objection is against too general option. Every option shoudl to do one clean thing.

Regards

Pavel
 


Regards,
Marko Tiikkaja

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Marko Tiikkaja
Дата:
Сообщение: Re: plpgsql.warn_shadow
Следующее
От: Mel Gorman
Дата:
Сообщение: Re: Linux kernel impact on PostgreSQL performance (summary v1 2014-1-15)