From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PoC plpgsql - possibility to force custom or generic plan |
Date: | 2017-01-24 05:38:45 |
Message-ID: | CAFj8pRA8PYc9Jr8m7tvbgjm3V-=aPgt8A2pW7AefSHYwyKpYtA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
2017-01-23 21:59 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:
> On 1/23/17 2:10 PM, Pavel Stehule wrote:
>
>> Comments, notes?
>>
>
> +1 on the idea. It'd also be nice if we could expose control of plans for
> dynamic SQL, though I suspect that's not terribly useful without some kind
> of global session storage.
>
> A couple notes on a quick read-through:
>
> Instead of paralleling all the existing namespace stuff, I wonder if it'd
> be better to create explicit block infrastructure. AFAIK PRAGMAs are going
> to have a lot of the same requirements (certainly the nesting is the same),
> and we might want more of this king of stuff in the future. (I've certainly
> wished I could set a GUC in a plpgsql block and have it's settings revert
> when exiting the block...)
>
I am not sure if I understand. ?? Setting GUC by PRAGMA can work - the
syntax supports it and GUC API supports nesting. Not sure about exception
handling - but it should not be problem probably.
Please, can you show some examples.
> Perhaps that's as simple as renaming all the existing _ns_* functions to
> _block_ and then adding support for pragmas...
>
> Since you're adding cursor_options to PLpgSQL_expr it should probably be
> removed as an option to exec_*.
>
I have to recheck it. Some cursor options going from dynamic cursor
variables and are related to dynamic query - not query that creates query
string.
>
> finit_ would be better named free_.
good idea
Regards
Pavel
>
> --
> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
> Experts in Analytics, Data Architecture and PostgreSQL
> Data in Trouble? Get it in Treble! http://BlueTreble.com
> 855-TREBLE2 (855-873-2532)
>
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2017-01-24 05:43:41 | Re: PoC plpgsql - possibility to force custom or generic plan |
Previous Message | Michael Paquier | 2017-01-24 05:32:56 | Re: Assignment of valid collation for SET operations on queries with UNKNOWN types. |