Re: proposal: plpgsql pragma statement

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: plpgsql pragma statement
Дата
Msg-id CAFj8pRChFr+RJKQBYU5AgxbL0kZBpiv4WB6LtgJEt6Hioj9r_g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: plpgsql pragma statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: proposal: plpgsql pragma statement  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers


čt 6. 12. 2018 v 18:05 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:


čt 6. 12. 2018 v 17:57 odesílatel Robert Haas <robertmhaas@gmail.com> napsal:
On Thu, Dec 6, 2018 at 11:39 AM Jonah H. Harris <jonah.harris@gmail.com> wrote:
> IIRC, PRAGMA in Ada was compile-time only. How would you foresee it affecting runtime?

Well, I don't know what Ada does with PRAGMA exactly, but look at
these examples from Oracle:

http://psoug.org/definition/pragma.htm

You wouldn't *execute* those at runtime, but at least for some of
them, the runtime behavior would depend on whether or not they were
specified.  It certainly seems possible that we might want to have
similar things.

My proposal doesn't block it.

The pragma in Ada has three levels - function, block, statement. I propose (in this moment) just statement level syntax, but I am sure, so other levels are possible.

My idea about plpgsql PRAGMA is very close to PL/SQL or Ada PRAGMA. This is not runtime statement - the information from this command will be assigned to related object - function, block, command at parser time.


I would to have a autonomous functions or autonomous blocks too, and Ada syntax (same with PL/SQL) is good.

Regards

Pavel




--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: slow queries over information schema.tables
Следующее
От: Robert Haas
Дата:
Сообщение: Re: proposal: plpgsql pragma statement