Re: Understanding DateStyle guc in startup packet

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 PM Manav Kumar <mkumar(at)yugabyte(dot)com> wrote:

> 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(at)yugabyte(dot)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(dot)vladimir(at)gmail(dot)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
>>>
>>>