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 1uINv5-003W5T-W2 for pgsql-jdbc@arkaria.postgresql.org; Fri, 23 May 2025 08:38:24 +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 1uINv4-00H3Vd-FI for pgsql-jdbc@arkaria.postgresql.org; Fri, 23 May 2025 08:38:22 +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 1uINv4-00H3VK-2t for pgsql-jdbc@lists.postgresql.org; Fri, 23 May 2025 08:38:22 +0000 Received: from mail-qv1-xf2a.google.com ([2607:f8b0:4864:20::f2a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uINv1-000Two-1A for pgsql-jdbc@lists.postgresql.org; Fri, 23 May 2025 08:38:20 +0000 Received: by mail-qv1-xf2a.google.com with SMTP id 6a1803df08f44-6f0c30a1ca3so87644246d6.1 for ; Fri, 23 May 2025 01:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yugabyte.com; s=google; t=1747989499; x=1748594299; 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=MYwkzrQcxu60U0W/kOLPmTKaTKQf4CJk/AwnoIb/Ees=; b=RnSYUReQSMUciOzLBDJLzyqgWAs1LQKDvPm3C1oxE3ICPPZ9sHdL746r/Xa0fa6Coe yIGbKOU+jRhcG46Risgd4CD6mNbhO7a4c+I7A79qGHcACsRDLCqvwIPOlolAxN7Hm1PX DoQ6SryVlLIiVT3C6zVsaHh7Ouls43W7Mu164= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747989499; x=1748594299; 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=MYwkzrQcxu60U0W/kOLPmTKaTKQf4CJk/AwnoIb/Ees=; b=GA6Z3ghr9d6yfAZgZyAvkC5rlxxBZWtrOkELSL9juGNLlnOUAtWSULQ7/Mz403xhoG N6+I/ZN0FvL48sMnlXpIgUWVglXypQN1Xuoh9pkEcDnCI961+nGTmHlvnZRYz6mLnzLP 0pDnScPw+AJszHWIWARaIc5gPG72bb5j7V2bVi8H+1WpMvom0Vx9aPHm97GRb1dRHCUU JOuFVZT/1JBsj5NjPgfeuji+qneH9AOdDDUcB1FV9Y84CDK+2KU152zIZoIRMyR4h2Ck G9taGgx5WLu8TJC3gYcevTqSp3XSV5+xsrErowmteZqxuG7TF+R6F3tU/jbmvdu9Tr7u chVg== X-Gm-Message-State: AOJu0YxpJpMRRvF6mkLr5a/B4iiue8QjCCj2y5goCqyeq1XVS6nz10Y8 te2S3FyQuZNCB52jvPVxaaKYXdxrlubwHphrHDR4i12E9jKR37KIbUo9etqZ75icFZaCNxTYnaq VFpXN1LUHmm58fzX4QrufBehJy158ZMEbxHMFsZVdUw== X-Gm-Gg: ASbGncvL1opt43SDJMwyzI6VCWnQdC3Wvk6tU4t2bVM3KzWDKWWQl4/xLCcvPmJLJHh vQYB9U8uy4HTniV9Sn5Dyh6X1m2Cobk7ChZmOcuEFrFYubOp3ihGbeH6BGKDX3AG5eXNuLXc0dt 8joHR+AytjD5OYWKD7tf33jn1pHT4Nb/52JatiiAyP4ooqLWFUsgoE7oc9/VyVTtoDd3rlt+/wF eG6CA== X-Google-Smtp-Source: AGHT+IG+xUhxKxklV9YrhdHIIuKgnrJMCAJNP1qnjJHDnUMubfI+FR01c/w6ixf+muSe7y+eazSj9jbGnPG6dzAqg/Q= X-Received: by 2002:a05:6214:212b:b0:6f4:c824:9d4a with SMTP id 6a1803df08f44-6f8b0841f3fmr461652806d6.13.1747989498734; Fri, 23 May 2025 01:38:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Manav Kumar Date: Fri, 23 May 2025 14:08:07 +0530 X-Gm-Features: AX0GCFsvvTluKVRjdsh8lkWeXna4JyfIMiEVsxWyC5cWfhA2yRMe6xrjbF7qwjI Message-ID: Subject: Re: Understanding DateStyle guc in startup packet To: Vladimir Sitnikov Cc: pgsql-jdbc@lists.postgresql.org, Laurenz Albe Content-Type: multipart/alternative; boundary="00000000000024bd6c0635c985b2" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000024bd6c0635c985b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable cc: Laurenz, pgsql-jdbc. Hi, Can you also share how does DRIVER comes to know the value been set for DateStyle is other than "ISO". and throw an error: The server's DateStyle parameter was changed to Postgres, DMY. The JDBC driver requires DateStyle to begin with ISO for correct operation. I thought it used to read the PARAMETER STATUS packet that it receives from the server. But I tried changing it connection pooler i doens't see the same error. Can you point me to code where this assert check is present. On Thu, May 22, 2025 at 6:23=E2=80=AFPM Manav Kumar w= rote: > Hi, > Can you also share how does DRIVER comes to know the value been set for > DateStyle is other than "ISO". and throw an error: > The server's DateStyle parameter was changed to Postgres, DMY. The JDBC > driver requires DateStyle to begin with ISO for correct operation. > > I thought it used to read the PARAMETER STATUS packet that it receives > from the server. But I tried changing it connection pooler i doens't see > the same error. Can you point me to code where this assert check is > present. > > On Mon, May 19, 2025 at 11:31=E2=80=AFPM Manav Kumar wrote: > >> Got it. >> Let me know if you think my understanding is correct. >> The way these special GUC's are being set is: >> https://github.com/pgjdbc/pgjdbc/blob/d9e20874590f59543c39a99b824e09344f= 00a813/pgjdbc/src/main/java/org/postgresql/core/v3/ConnectionFactoryImpl.ja= va#L409 >> >> "DateStyle" : "ISO" >> "Client_encoding": "UTF8". >> >> And when we pass >> "options": "DateStyle=3DPostgres,DMY" >> I think it takes less precedence in the server than if the direct key as >> a guc variable is passed as key. >> >> This can be verified from below codes i found on server side: >> >> https://github.com/postgres/postgres/blob/29f7ce6fe78e3f8d520764b5870453= d791a3ca65/src/backend/utils/init/postinit.c#L1262 >> - First cmd line options are processed i.e -options. >> >> Followed by >> >> https://github.com/postgres/postgres/blob/29f7ce6fe78e3f8d520764b5870453= d791a3ca65/src/backend/utils/init/postinit.c#L1294 >> - Followed by GUC options are set/overriden. >> >> "DateStyle", "Client_encoding" etc all comes into guc_options as general >> GUC options. >> https://github.com/postgres/postgres/blob/29f7ce6fe78e3f8d520764b5870453= d791a3ca65/src/backend/tcop/backend_startup.c#L787 >> >> >> >> >> My next question is: Suppose i comment the code to set the value of >> "DateStyle" to "ISO" from startup where key is my "DateStyle". >> The error I get is: >> org.postgresql.util.PSQLException: The server's DateStyle parameter was >> changed to Postgres, DMY. The JDBC driver requires DateStyle to begin wi= th >> ISO for correct operation. >> at >> org.postgresql.core.v3.QueryExecutorImpl.receiveParameterStatus(QueryExe= cutorImpl.java:2887) >> *Questions *is how does the driver comes to know which value has been >> set on server, is it due to PARAMETER STATUS which is been returned for = the >> "DateStyle" on getting set and it contains the value as "Postgres,DMY" a= nd >> driver reads this value to throw an error as it doesn't matches "ISO". I= s >> it correct ? >> >> >> Thanks a lot for giving me all hints and help! >> Best >> Manav >> >> >> >> >> >> On Mon, May 19, 2025 at 9:07=E2=80=AFPM Vladimir Sitnikov < >> sitnikov.vladimir@gmail.com> wrote: >> >>> >Why would you want to change it? >>> >>> Applications might have their own view on the way DateStyle connection >>> property should be set. >>> It could make a difference if the app uses things like select >>> '03-05-2025'::date. >>> >>> Of course, it would be great if the app code could resist from casting >>> text to dates, however, >>> I think the driver should stand in the way there by enforcing a very >>> specific DateStyle value. >>> >>> To me, DateStyle looks like timezone, and client_encoding which we >>> currently enforce, yet we could do better and skip enforcing the values= . >>> >>> Vladimir >>> >>> --00000000000024bd6c0635c985b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
cc: Laurenz, pgsql-jdbc.=C2=A0
Hi,=C2=A0
Can you als= o share how=C2=A0does DRIVER comes to know the value been set for DateStyle= is other than "ISO". and throw an error:
=C2=A0The server's DateStyle paramet= er was changed to Postgres, DMY. The JDBC driver requires DateStyle to begi= n with ISO for correct operation.=C2=A0

I thought it used to = read the PARAMETER STATUS packet that it receives from the server. But I tr= ied changing it connection pooler i doens't see the same error. Can you= point me to code where this assert check is present.=C2=A0=C2=A0


On Thu, May 22, 2025 at 6:23=E2=80=AFPM Ma= nav Kumar <mkumar@yugabyte.com> wrote:
Hi,=C2=A0
Can you also share how=C2=A0does DRIVER comes to= know the value been set for DateStyle is other than "ISO". and t= hrow an error:
=C2=A0The server's DateStyle parameter was changed t= o Postgres, DMY. The JDBC driver requires DateStyle to begin with ISO for c= orrect operation.=C2=A0

I thought it used to read the PARAMETER STAT= US packet that it receives from the server. But I tried changing it connect= ion pooler i doens't see the same error. Can you point me to code where= this assert check is present.=C2=A0

On Mon, May 19, 2025 at 11:31=E2= =80=AFPM Manav Kumar <mkumar@yugabyte.com> wrote:
Got it.
Let me know if you th= ink my understanding is correct.=C2=A0
"Client_encoding&qu= ot;: "UTF8".

And when we pass=C2=A0
"options": "DateStyle=3DPostgres,DMY"=C2=A0
=
I think it takes less precedence in the server than if the direct key = as a guc variable is passed as key.=C2=A0

This can= be verified from below codes i found on server side:

Followed by

"DateStyle", &q= uot;Client_encoding" etc all comes into guc_options as general GUC opt= ions.=C2=A0https://github.com/postgres/postgres/blob/29f7ce6fe78e3f8d520= 764b5870453d791a3ca65/src/backend/tcop/backend_startup.c#L787=C2=A0



My next question is: Su= ppose i comment the code to set the value of "DateStyle" to "= ;ISO" from startup where key is my "DateStyle".
Th= e error I get is:=C2=A0
org.postgresql.util.PSQLException: The se= rver's DateStyle parameter was changed to Postgres, DMY. The JDBC drive= r requires DateStyle to begin with ISO for correct operation.
at org.= postgresql.core.v3.QueryExecutorImpl.receiveParameterStatus(QueryExecutorIm= pl.java:2887)
Questions is how does the driver comes to know whi= ch value has been set on server, is it due to PARAMETER STATUS which is bee= n returned for the "DateStyle" on getting set and it contains the= value as "Postgres,DMY" and driver reads this value to throw an = error as it doesn't matches "ISO". Is it correct ?
=

Thanks a lot for giving me all hints and help= !
Best
Manav



=


On Mon, May 19, 2025 at 9:07=E2=80=AFPM Vladimir= Sitnikov <sitnikov.vladimir@gmail.com> wrote:
>= ;Why would you want to change it?

Applications mig= ht have their own view on the way DateStyle connection property should be s= et.
It could make a difference if the app uses things like select= '03-05-2025'::date.

Of course, it would be great= if the app code could resist from casting text to dates, however,
I think the driver should stand in the way there by enforcing a very spec= ific DateStyle value.

To me, DateStyle looks like = timezone, and=C2=A0client_encoding which we currently enforce, yet we could= do better and skip enforcing the values.

Vladimir

--00000000000024bd6c0635c985b2--