Tom Lane <t...@sss.pgh.pa.us> writes: >> Or do you want to open SET typo.wrogn TO 'foobar' to just work silently? > > Well, right at the moment it *does* work silently, as long as the prefix > is one you listed in custom_variable_classes. I don't think we want to > take that away, and in particular I don't want to assume that every > variable will be declared in advance. It's a fairly safe bet that there > are some apps out there that would be broken by such a requirement.
Fair enough I suppose. But I think we could break that requirement if we offer a good enough way out. > At the same time, I'd kind of like to see a facility for declaring such > variables, if only so you could define them to be bool/int/real not just > strings. But this is getting far afield from the immediate proposal, > and no I'm not volunteering to do it. I think we are able to handle that part when dealing with C extension's GUCs, because those are declared in the .so. We only need to add them to the control file, the only road block here used to be c_v_c. What I have in mind for extensions now that c_v_c is out would be to be able to declare any GUC in the control file, with default values, and without forcing extension to handle the GUC in its .so — I don't think we have to change the code beside removing the c_v_c checks here. In the general case, how far exposing DefineCustomBoolVariable and all at the SQL level would get us? Then you could allow the session to add any new GUC by calling that first, SET would bail out if given unknown variable. Yes, it would still break some existing applications, but I think it'd be worth it (and an easy fix too, as I guess most shared variables are going to be used in PL code, and if you ask me this code should now be an extension and the control file would then declare the GUCs). Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
