On Mon, Oct 3, 2011 at 00:05, Tom Lane 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 telephone num
Tom Lane 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 anyway.
>> We could
Dimitri Fontaine writes:
> Tom Lane writes:
>> Dimitri Fontaine 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 thi
Tom Lane writes:
> Dimitri Fontaine 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 b
Dimitri Fontaine 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 beside removing the c_v
Tom Lane 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 as
Dimitri Fontaine writes:
> Tom Lane 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 work silently?
Well, right at the
Tom Lane writes:
> Dimitri Fontaine 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 custom_variabl
Dimitri Fontaine 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 custom_variable_classes, right?
No, b
David Fetter 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 whatever.
Who
On Mon, Oct 3, 2011 at 12:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Oct 3, 2011 at 11:16 AM, Tom Lane wrote:
>>> Robert Haas 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 preve
Robert Haas writes:
> On Mon, Oct 3, 2011 at 11:16 AM, Tom Lane wrote:
>> Robert Haas 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 poin
On Mon, Oct 3, 2011 at 11:16 AM, Tom Lane wrote:
> Robert Haas 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
>> se
Robert Haas 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 sure it has enough
On Mon, Oct 3, 2011 at 10:55 AM, David Fetter 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 care of clea
On Mon, Oct 03, 2011 at 10:41:48AM -0400, Tom Lane wrote:
> Andrew Dunstan 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
Andrew Dunstan 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
> mechanism?
On 10/03/2011 10:17 AM, Tom Lane wrote:
Magnus Hagander 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, th
Magnus Hagander 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 could just
> rewr
On Sun, Oct 2, 2011 at 23:05, Tom Lane 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 his patch just n
Tom Lane writes:
> Simon Riggs writes:
>> On Sun, Oct 2, 2011 at 10:05 PM, Tom Lane 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 sensi
Simon Riggs writes:
> On Sun, Oct 2, 2011 at 10:05 PM, Tom Lane 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 sensible. One less thing to con
On Sun, Oct 2, 2011 at 10:05 PM, Tom Lane 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 his patch jus
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 t
24 matches
Mail list logo
