On Mon, Oct 3, 2011 at 00:05, Tom Lane t...@sss.pgh.pa.us wrote:
So at this point I'd vote for just dropping it and always allowing
custom (that is, qualified) GUC names to be set, whether the prefix
corresponds to any loaded module or not.
Comments, other proposals?
While working on E.164
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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
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
Tom Lane t...@sss.pgh.pa.us writes:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
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
Tom Lane t...@sss.pgh.pa.us writes:
I still don't see the point. If they want to change the default
setting, they add an entry to postgresql.conf. Problem solved.
As you wish. They will have to figure the current defaults in some
other way then edit the file. That's good enough for now
Tom Lane t...@sss.pgh.pa.us writes:
Simon Riggs si...@2ndquadrant.com writes:
On Sun, Oct 2, 2011 at 10:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So at this point I'd vote for just dropping it and always allowing
custom (that is, qualified) GUC names to be set, whether the prefix
corresponds
On Sun, Oct 2, 2011 at 23:05, Tom Lane t...@sss.pgh.pa.us wrote:
During the discussion of Alexey Klyukin's rewrite of ParseConfigFile,
considerable unhappiness was expressed by various people about the
complexity and relative uselessness of the custom_variable_classes GUC.
While working over
Magnus Hagander mag...@hagander.net writes:
Don't forget that there are usecases for variables under
custom_variable_classes that aren't actually associated with
extensions (as general session-shared-variables). Though I guess if it
was somehow restricted to extensions, those who needed that
On 10/03/2011 10:17 AM, Tom Lane wrote:
Magnus Hagandermag...@hagander.net writes:
Don't forget that there are usecases for variables under
custom_variable_classes that aren't actually associated with
extensions (as general session-shared-variables). Though I guess if it
was somehow
Andrew Dunstan and...@dunslane.net writes:
On 10/03/2011 10:17 AM, Tom Lane wrote:
Right. Getting rid of custom_variable_classes should actually make
those use-cases easier, since it will eliminate a required setup step.
So are we going to sanction using this as a poor man's session variable
On Mon, Oct 03, 2011 at 10:41:48AM -0400, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 10/03/2011 10:17 AM, Tom Lane wrote:
Right. Getting rid of custom_variable_classes should actually
make those use-cases easier, since it will eliminate a required
setup step.
So
On Mon, Oct 3, 2011 at 10:55 AM, David Fetter da...@fetter.org wrote:
Perhaps it's best to document this usage and include the warning for
those less bright, as you term them. I'd be less tempted to call
them not bright and more tempted to think they might assume
PostgreSQL already takes
Robert Haas robertmh...@gmail.com writes:
Yeah. custom_variable_classes is a pretty annoying wart, but if it's
set to the default value (namely, empty) then it actually does prevent
people from setting bajillions of completely pointless settings, which
seems like it has some merit. I'm not
On Mon, Oct 3, 2011 at 11:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah. custom_variable_classes is a pretty annoying wart, but if it's
set to the default value (namely, empty) then it actually does prevent
people from setting bajillions of
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 3, 2011 at 11:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah. custom_variable_classes is a pretty annoying wart, but if it's
set to the default value (namely, empty) then it actually does prevent
On Mon, Oct 3, 2011 at 12:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 3, 2011 at 11:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah. custom_variable_classes is a pretty annoying wart, but if it's
set
David Fetter da...@fetter.org writes:
Perhaps it's best to document this usage and include the warning for
those less bright, as you term them. I'd be less tempted to call
them not bright and more tempted to think they might assume
PostgreSQL already takes care of cleaning this up, but
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Another compromise might be to allow for defining variable in any class
from the configuration files but restrict that to existing classes from
the SET command. Wait, that's exactly what happens as soon as there's
no explicit
Tom Lane t...@sss.pgh.pa.us writes:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Another compromise might be to allow for defining variable in any class
from the configuration files but restrict that to existing classes from
the SET command. Wait, that's exactly what happens as soon as
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
No, because there are people who do intentionally use placeholder
variables as session-local storage, and that would be taking away
that capability.
Or do you want to open SET typo.wrogn TO 'foobar' to just
During the discussion of Alexey Klyukin's rewrite of ParseConfigFile,
considerable unhappiness was expressed by various people about the
complexity and relative uselessness of the custom_variable_classes GUC.
While working over his patch just now, I've come around to the side that
was saying that
On Sun, Oct 2, 2011 at 10:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
During the discussion of Alexey Klyukin's rewrite of ParseConfigFile,
considerable unhappiness was expressed by various people about the
complexity and relative uselessness of the custom_variable_classes GUC.
While working
Simon Riggs si...@2ndquadrant.com writes:
On Sun, Oct 2, 2011 at 10:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So at this point I'd vote for just dropping it and always allowing
custom (that is, qualified) GUC names to be set, whether the prefix
corresponds to any loaded module or not.
Sounds
24 matches
Mail list logo
