Re: Unable to set guc via setProperty

On Fri, Jun 20, 2025 at 1:11 PM Dave Cramer <davecramer(at)postgres(dot)rocks>
wrote:

>
>
> On Fri, 20 Jun 2025 at 10:23, David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
>> On Friday, June 20, 2025, Manav Kumar <mkumar(at)yugabyte(dot)com> wrote:
>>
>>> Hi Team,
>>> I've a doubt regarding passing guc variables in start up packet as key
>>> value pairs instead of in options.
>>>
>>> I'm unable to set jdbc:postgresql://10.150.3.175:6433/postgres?&geqo=off
>>> m geqo to 'off'. I don't want to use "options" rather pass directly key
>>> value pairs similar to what JDBC driver internally does.
>>>
>>
>>> Neither setProperty("geqo", "off") works in this case.
>>> Can someone let me know why I can't do it?
>>>
>>
>> Probably because that isn’t how things work…connection properties are set
>> using set property and gucs aren’t connection properties - though there is
>> a pass-through connection property called options that can hold a list of
>> gucs to set.
>>
> David, for my elucidation are they GUC's ? The docs state:
> "Command-line arguments for the backend. (This is deprecated in favor of
> setting individual run-time parameters.) Spaces within this string are
> considered to separate arguments, unless escaped with a backslash (\);
> write \\ to represent a literal backslash."
>

geqo is a GUC
https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-GEQO

And to pass GUCs into the postgres server process you bundle them up into
the "options" cli argument via the "options" parameter keyword that you've
quoted.

I do not see that deprecation warning in v18 documentation.

https://www.postgresql.org/docs/devel/libpq-connect.html#LIBPQ-CONNECT-OPTIONS

While some GUCs are also connection parameters (e.g., application_name) and
thus can be used directly most GUCs are not and much get lumped into
options.

David J.