Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uSj5I-00CH64-VU for pgsql-jdbc@arkaria.postgresql.org; Fri, 20 Jun 2025 21:15:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uSj5G-004OtJ-M4 for pgsql-jdbc@arkaria.postgresql.org; Fri, 20 Jun 2025 21:15:39 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uSj5G-004OtB-Ab for pgsql-jdbc@lists.postgresql.org; Fri, 20 Jun 2025 21:15:39 +0000 Received: from mail-oo1-xc30.google.com ([2607:f8b0:4864:20::c30]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uSj5E-0037Il-2c for pgsql-jdbc@lists.postgresql.org; Fri, 20 Jun 2025 21:15:37 +0000 Received: by mail-oo1-xc30.google.com with SMTP id 006d021491bc7-60ef850d590so601760eaf.3 for ; Fri, 20 Jun 2025 14:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750454136; x=1751058936; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/8uF1PjTYpNPLVr2W35hF/s3/SH7fLzn8Pbtj+1t2Vg=; b=bfsmb2dmfGigb0dWgIezZiQVMDK5FXnXRm5vzhLv22IDNPRYxMd6dHORRFfbzaHDh0 N/B0lQzn3rdvYXG3sx8Dby7wUEB6f8FBVbIyi3UTe48PBcDW4/bVxS3w7bGMztRmUOH7 xkqEEPWaMdLOHYjZ6yb71wDAmMfOLBmz5vQmbTBWsrgvclCh01pwNmedKVLUfa01W/6K cLJ5WDxCecpvcihxjUF6YmNbFkyEDteNOAN6mzrwe7TiIIkJ+cJ7VtRaD9UoU7jq1C9w jcan1BKzfWppLYmgMv7nyaGKnMLnKev5v8cFrgha6Haufmp9yJ1LxpKnqdjbO3GE8PhF mWnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750454136; x=1751058936; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/8uF1PjTYpNPLVr2W35hF/s3/SH7fLzn8Pbtj+1t2Vg=; b=WG5oBhkDtHQALkPP8uzUtRX/lKP6v0CmJb451xeT2NWbIe1g9YKRCw5D7wva7wRhVn 9d2FuqsPFEbeI8s8ad82T8doMLCXahACG6YU0upJxGukvl0yF7Z8uS8PwaoqL5LuAi1E CaWFBr2+TZM4wIR6Dv4z+1DJGQUxsE/9EGJlNXTOxQHQfdejuYeZOSKteyYbh5+mqrUa Iq74hVM8BSVEiu+IugquZ6T/myhwVHdNd03tgfVOue78n4tsXnJ/ExJtoGcbMnfDuT0F 4Kx7Kh2wLaDy2gMR95yj1cEddrkcEYtsqUN8dLYwxkiWsWcF++wvm4aP4EcsgfR7MLUf DT7Q== X-Forwarded-Encrypted: i=1; AJvYcCUe8Alp993i1mtE+rk0FeDy7EYgYWx87xue2sZjMjgRYnd9Yk07AcvYkc3bWIBdf8sHdSof7gr279rk@lists.postgresql.org X-Gm-Message-State: AOJu0YwhgdXitvo0fVMKu0+fl32eYB0W5rAer2jeHc1n1sF9YoCepIef jxqOm9ysWIuh713Efrf8jwzAol4mk+IrExOJMhVO7DeoSEq7gtdH5x8sr9I+iGe08cnfdBHtSqn 874SuLH75nGvP/NaQfnCRG9LgC4rI3UI= X-Gm-Gg: ASbGnctgqUel+wQungeyMJy2StrvbzJSAEA3edSED3CIv6rcqZqg60z4rtNNShXWIsj A+EoIzULgKRowQz0HDxBu+OjZilCFglG5SR3I9nxtTHyBqlRFEV8/Ic7pnI9UW6VfFi6e8SRvfU lq/AqYPHDIpW+1vvigQmdxgVZz/Eb2JqnJW+QZasjxO1pp1qfU83m04/K56FfR6qmxGhn77xSB4 6nH X-Google-Smtp-Source: AGHT+IH08icAQ2KR9M7EdHv8aLZBr+eE8SjLB7HTmGAr68PFOmWxyOgOfsUBxdd2ufnVDkYv2frq1rxzJqaoIPHlD3U= X-Received: by 2002:a05:6871:d082:b0:2e9:1e11:3183 with SMTP id 586e51a60fabf-2eeda4bba1cmr3045727fac.8.1750454135828; Fri, 20 Jun 2025 14:15:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "David G. Johnston" Date: Fri, 20 Jun 2025 14:14:59 -0700 X-Gm-Features: AX0GCFsuZTQwCsVX-WA_7NdTv5tu3BGPQCj1JESDVR699k0carfQIg3-Fqev30Q Message-ID: Subject: Re: Unable to set guc via setProperty To: Dave Cramer Cc: Manav Kumar , "pgsql-jdbc@lists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000f633620638075cb8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f633620638075cb8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 20, 2025 at 1:11=E2=80=AFPM Dave Cramer wrote: > > > On Fri, 20 Jun 2025 at 10:23, David G. Johnston < > david.g.johnston@gmail.com> wrote: > >> On Friday, June 20, 2025, Manav Kumar 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=3D= 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=E2=80=99t how things work=E2=80=A6connection p= roperties are set >> using set property and gucs aren=E2=80=99t connection properties - thoug= h there is >> a pass-through connection property called options that can hold a list o= f >> 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-OPTI= ONS 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. --000000000000f633620638075cb8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 20, 2025 at 1:11=E2=80=AFPM Dave Cramer <da= vecramer@postgres.rocks> wrote:

<= br>
On Fri,= 20 Jun 2025 at 10:23, David G. Johnston <david.g.johnston@gmail.com> wrote:=
On Friday, June= 20, 2025, Manav Kumar <mkumar@yugabyte.com> wrote:
Hi Team,
I've a doubt regard= ing passing guc variables=C2=A0in start up packet as key value pairs instea= d of in options.=C2=A0

I'm unable=C2=A0to set= =C2=A0jdbc:postgresql://10.150.3.175:6433/postgres?&= ;geqo=3Doff
m geqo to 'off'. I don't want= to use "options" rather pass directly key value pairs similar to= what JDBC driver internally does. =C2=A0

Neither=C2=A0setProperty("geqo", "off") works in thi= s case.
Can someone let me know why I can't do it?=C2=A0

Probably because that isn=E2=80=99t= how things work=E2=80=A6connection properties are set using set property a= nd gucs aren=E2=80=99t connection properties - though there is a pass-throu= gh connection property called options that can hold a list of gucs to set.<= /div>
David, for my elucidation are they GUC's ? The d= ocs state:
"Command-line arguments for t= he backend. (This is deprecated in favor of setting individual r= un-time parameters.) Spaces within this string are considered to separate a= rguments, unless escaped with a backslash (\); write=C2=A0\\=C2=A0to represent a literal backslash.&q= uot;=C2=A0

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">geqo is a GUC
https://www.postgresql.org/docs/current= /runtime-config-query.html#GUC-GEQO

And to pass GU= Cs into the postgres server process you bundle them up into the "optio= ns" cli argument via the "options" parameter keyword that yo= u've quoted.

I do=C2=A0not=C2=A0see that deprecati= on 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 mu= ch get lumped into options.

David J.
--000000000000f633620638075cb8--