Re: proposal: plpgsql pragma statement

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: plpgsql pragma statement
Дата
Msg-id CAFj8pRD1er3WyGvhEKs0CkBg157StYr4CBQFaVvDE=y_yDqYnA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: plpgsql pragma statement  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Ответы Re: proposal: plpgsql pragma statement
Список pgsql-hackers


čt 7. 3. 2019 v 18:45 odesílatel Andrew Dunstan <andrew.dunstan@2ndquadrant.com> napsal:

On 3/7/19 12:41 PM, Pavel Stehule wrote:
>
>
> čt 7. 3. 2019 v 18:35 odesílatel Andrew Dunstan
> <andrew.dunstan@2ndquadrant.com
> <mailto:andrew.dunstan@2ndquadrant.com>> napsal:
>
>
>
>
>     The other thing that bugs me a bit about the patch is that the only
>     testing it does it to make sure that pragmas are ignored by the core
>     plpgsql processor. Maybe that's enough, but mostly we tend to like to
>     have one actual use of a feature.
>
>
> Unfortunately plpgsql_check is not part of upstream
>
> https://github.com/okbob/plpgsql_check
>
> I can to write some simple extension - some print tracing, that can
> use this feature?
>
>

Works for me. Another idea I had was some sort of crypto signature pragma.

Here is pragma patch with demo

Regards

Pavel


I still think making it block level only is unwarranted, though.


cheers


andrew


--
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Should we increase the default vacuum_cost_limit?
Следующее
От: Paul Martinez
Дата:
Сообщение: Re: PATCH: Include all columns in default names for foreign key constraints.