Re: Document DateStyle effect on jsonpath string()
Peter Eisentraut <peter@eisentraut.org>
From: Peter Eisentraut <peter@eisentraut.org>
To: "David E. Wheeler" <david@justatheory.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: jian he <jian.universality@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-09-10T20:10:47Z
Lists: pgsql-hackers
Isn't this behavior actually a bug that should be fixed rather than documented? These JSON path functions are specified by the SQL standard, so they shouldn't depend on PostgreSQL-specific settings. At least in new functionality we should avoid that, no? On 10.09.24 21:43, David E. Wheeler wrote: > On Sep 10, 2024, at 14:51, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Pushed with a little additional polishing. > > Thank you! Do you think it’d be worthwhile to back port to 17? > >> I thought the best way to address jian's complaint about DateStyle not >> being clearly locked down was to change horology.sql to verify the >> prevailing setting, as it has long done for TimeZone. That's the >> lead test script for related stuff, so it makes the most sense to >> do it there. Having done that, I don't feel a need to duplicate >> that elsewhere. > > Yeah, that will help, but I still bet next time I go to figure out what it is I’ll stick that line in some test to make it fail with clear output for what it’s set to 😂.
Commits
-
Make jsonpath .string() be immutable for datetimes.
- cc4fdfa411fa 17.0 landed
- cb599b9ddfcc 18.0 landed
-
Improve documentation and testing of jsonpath string() for datetimes.
- ed055d249df5 18.0 landed