On Sun, Aug 14, 2016 at 12:13 PM, Xtra Coder <xtracoder@xxxxxxxxx> wrote:
Thanks, I'm aware about ability to create temp functions, but this is actually too much overhead - I mean unneeded boilerplate code, but it seems in current state it is "the least evil" which I have to use.I think 'what i need' is support for following- ability to switch session language from 'sql' to 'pl/pgsql'- in that mode - ability to declare session-scope variables, 'DO' is just not needed after that- SELECTs not targeted into a variable - are written to client output- (C) Merlin Moncure - "Ability to embed collection of statements in the database under a name and invoke those statements via CALL <name>, which does not automatically create a transaction and a snapshot (unlike functions/DO)"All this seems to be a huge change which will definitely not appear any time soon.
I am willing to bet that DO $$ $$; blocks are neither planned nor parameterized. And the planner needs to know what is to be returned.
So anything you add to make DO work well with the planner will probably end you right back at the same amount of overhead as a temporary function.
On Sun, Aug 14, 2016 at 10:42 AM, Chris Travers <chris.travers@xxxxxxxxx> wrote:If all you want is a temporary function, you *can* create it in the pg_temp namespace though that seems hackish.Maybe a better solution would be to extend CREATE FUNCTION in a way that allows you to CREATE TEMPORARY FUNCTION?...--Best Wishes,Chris TraversEfficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.
