Re: Understanding DateStyle guc in startup packet

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 PM Manav Kumar <mkumar@yugabyte.com> 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/d9e20874590f59543c39a99b824e09344f00a813/pgjdbc/src/main/java/org/postgresql/core/v3/ConnectionFactoryImpl.java#L409 
"DateStyle" : "ISO"

"Client_encoding": "UTF8".

And when we pass 

"options": "DateStyle=Postgres,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/29f7ce6fe78e3f8d520764b5870453d791a3ca65/src/backend/utils/init/postinit.c#L1262 - First cmd line options are processed i.e -options.

Followed by

https://github.com/postgres/postgres/blob/29f7ce6fe78e3f8d520764b5870453d791a3ca65/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/29f7ce6fe78e3f8d520764b5870453d791a3ca65/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 with ISO for correct operation.

at org.postgresql.core.v3.QueryExecutorImpl.receiveParameterStatus(QueryExecutorImpl.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" 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 PM 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