Re: proposal: plpgsql pragma statement - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: plpgsql pragma statement
Date
Msg-id CAFj8pRChFr+RJKQBYU5AgxbL0kZBpiv4WB6LtgJEt6Hioj9r_g@mail.gmail.com
Whole thread Raw
In response to Re: proposal: plpgsql pragma statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal: plpgsql pragma statement  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: slow queries over information schema.tables
Next
From: Robert Haas
Date:
Subject: Re: proposal: plpgsql pragma statement