I wrote:
> Well, if there are no other comments, I'll push forward with the fix
> proposed here:
> http://archives.postgresql.org/pgsql-hackers/2009-11/msg00531.php
Done. I did not make the change I speculated about of allowing
completely unknown variables (those that don't even match
custom_vari
Robert Haas writes:
> On Mon, Apr 19, 2010 at 10:29 PM, Tom Lane wrote:
>> The reason it seems of concern for 9.0 is that now we have a custom
>> SUSET variable in plpgsql. If we don't fix this then we need to think
>> hard about the alternative of forcing the variable into the core code
>> to a
On Mon, Apr 19, 2010 at 10:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 19, 2010 at 9:51 PM, Tom Lane wrote:
>>> The problem is that making a "custom" variable SUSET doesn't really
>>> work: the system will not accept a value that's assigned before the
>>> loadable module is loade
Robert Haas writes:
> On Mon, Apr 19, 2010 at 9:51 PM, Tom Lane wrote:
>> The problem is that making a "custom" variable SUSET doesn't really
>> work: the system will not accept a value that's assigned before the
>> loadable module is loaded, even if it was assigned by a superuser.
>> I suggested
On Mon, Apr 19, 2010 at 9:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> This thread is still on the open items list, as:
>> Improve behavior of SUSET GUC variables added by loadable modules?
>> Is there something that needs to be done here? If so, what is it?
>
> Well, if we knew exactly what
Robert Haas writes:
> This thread is still on the open items list, as:
> Improve behavior of SUSET GUC variables added by loadable modules?
> Is there something that needs to be done here? If so, what is it?
Well, if we knew exactly what to do, it wouldn't still be on the list.
The problem is th
On Thu, Nov 12, 2009 at 6:31 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> With all this fallout, I think it would be cleaner to step back and make
>> it a regular GUC variable, not custom. Pretending that plpgsql is
>> somehow not an integral part of the system is not completely true
>> anywa
Alvaro Herrera writes:
> With all this fallout, I think it would be cleaner to step back and make
> it a regular GUC variable, not custom. Pretending that plpgsql is
> somehow not an integral part of the system is not completely true
> anyway. Yes, we're playing favorites in the PL camp here, bu
Tom Lane escribió:
> I wrote:
> > Fair enough. I'll start writing the custom GUC then.
>
> While testing that, I noticed [...]
With all this fallout, I think it would be cleaner to step back and make
it a regular GUC variable, not custom. Pretending that plpgsql is
somehow not an integral part
I wrote:
> Fair enough. I'll start writing the custom GUC then.
While testing that, I noticed a pre-existing GUC limitation that maybe
we should do something about now: it does not work very nicely for
custom SUSET GUC variables. Normally, if a variable is SUSET, an
ordinary user can't do ALTER
Robert Haas writes:
> On Thu, Nov 12, 2009 at 11:13 AM, Tom Lane wrote:
>> One reason to argue for the other way is that maybe it wouldn't only
>> be consulted by plpgsql. In particular I can easily imagine SQL
>> functions having the same issue as soon as someone gets around to
>> letting them
On Thu, Nov 12, 2009 at 11:13 AM, Tom Lane wrote:
> One reason to argue for the other way is that maybe it wouldn't only
> be consulted by plpgsql. In particular I can easily imagine SQL
> functions having the same issue as soon as someone gets around to
> letting them use names for their paramet
So I think we're agreed on adding a variable_conflict GUC for plpgsql.
The straight-and-narrow way to do it would be to make this a custom
GUC that's defined only when plpgsql is dynamically loaded into the
backend. However that implies a lot of notational overhead, notably
having to put plpgsql i
13 matches
Mail list logo
