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) -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers