On 1/5/17 4:59 AM, Pavel Stehule wrote:
>
> - Personnaly, I'm not convinced that a NEW type of session variable is
> a good thing as pg already has one, and two is one too many. I would
> find it more useful to enhance existing dynamic session variables
> with,
> by order of importance:
>
> (1) private/public visibility (as Oracle does with package vars).
> this point is enough to implement the presented use case.
>
> (2) typing (casting is a pain)
>
> (3) improved syntax (set_config & current_setting is a pain)
>
> Eventually, unrelated to the use case, but in line with your
> motivations as I understand them:
>
> (4) add an option to make a GUC non transactional, iff there is
> a clear use case for that (maybe debug?).
>
> (5) have some "permanent" GUC type declarations (maybe editing the
> config file does that already, by the way?)
>
>
> Thank you for your work on this topic.
>
> Unfortunately, there is significant disagreement in this topic between
> us. I see a schema based persistent metadata a catalog based security as
> fundamental feature. Editing config file is not acceptable in any view.
I generally agree with that. That said, it probably wouldn't be hard to
"register" GUCs during backend startup, based on what's in the catalog
for the database you're connecting to. There's certainly already a place
in the code to do this, since you can set per-database values for GUCs.
That said, IIRC GUCs are setup in such a way that could could just
create a new stack upon connection. Actually, I think that'd need to
happen anyway, otherwise these variables are going to look like GUCs
even though they're not.
--
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)