On 24/10/14 23:07, Robert Haas wrote:
> On Fri, Oct 24, 2014 at 4:53 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> The only case I can think of would be actually connecting to a remote
>> database; in that case would we even want something as raw as this? I
>> suspect not, in which case I don't see an issue. On the other hand, if we
>> ever think we might want to do that, we should probably at least stick a
>> version number field in there...
>>
>> But my suspicion is if we ever wanted to do something more with this then
>> we'd want some kind of text-based format that could be passed into a SQL
>> command (ie: SET ENVIRONMENT TO blah;)
>
> I mean, I don't think this is much different than what we're already
> doing to transfer variables from the postmaster to other backends in
> EXEC_BACKEND builds; see write_nondefault_variables(). It doesn't
> have a version number or anything either. I don't see a reason why
> this code needs to be held to a different standard; the purpose is
> fundamentally quite similar.
>
I really do think that the GUC patch is ok as it is, we might want to do
1/0 for bools but I don't really see that as important thing. And it
works for the use-cases it's intended for. I don't see why this should
be required to work cross version really.
Loading of the modules by bgworker is probably bigger issue than just
GUCs, and I think it's out of scope for the current patch(set).
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services