On Sep 16, 2024, at 13:29, Tom Lane wrote:
> 17.0. If we were already past 17.0 I'd have a lot more angst
> about changing this behavior.
Great, very glad it made it in.
D
"David E. Wheeler" writes:
> BTW, will the back-patch to 17 (cc4fdfa) be included in 17.0 or 17.1?
17.0. If we were already past 17.0 I'd have a lot more angst
about changing this behavior.
regards, tom lane
On Sep 11, 2024, at 15:52, David E. Wheeler wrote:
> WFM, though now I’ll have to go change my port 😂.
I saw this was committed in cb599b9. Thank you!
BTW, will the back-patch to 17 (cc4fdfa) be included in 17.0 or 17.1?
Best,
David
On Sep 11, 2024, at 15:43, Tom Lane wrote:
> Seems to me it should be the jsonpath convention. If the spec
> does require any specific spelling, surely it must be that one.
WFM, though now I’ll have to go change my port 😂.
D
"David E. Wheeler" writes:
> Should it use the database-native stringification standard or the jsonpath
> stringification standard? In the case of the former, output should omit the
> “T” time separator and simplify the time zone `07:00` to `07`. But if it’s
> the latter case, then it’s good as
On Sep 11, 2024, at 15:08, Tom Lane wrote:
> Right. I actually lifted the code from convertJsonbScalar in
> jsonb_util.c.
>
> Here's a more fleshed-out patch with docs and regression test
> fixes. I figured we could shorten the tests a bit now that
> the point is just to verify that datestyle
"David E. Wheeler" writes:
> On Sep 11, 2024, at 12:26, Tom Lane wrote:
>> Building on that thought, maybe we could fix it as attached?
> It looks like that’s what datum_to_json_internal() in json.c does, which IIUC
> is the default stringification for date and time values.
Right. I actually
On Sep 11, 2024, at 12:26, Tom Lane wrote:
> Building on that thought, maybe we could fix it as attached?
> This changes the just-committed test cases of course, and I did
> not look at whether there are documentation changes to make.
It looks like that’s what datum_to_json_internal() in json.c
I wrote:
> I think I'd be content to have string() duplicate that behavior
> --- in fact, it seems like it'd be odd if it doesn't match.
Building on that thought, maybe we could fix it as attached?
This changes the just-committed test cases of course, and I did
not look at whether there are docume
"David E. Wheeler" writes:
> On Sep 11, 2024, at 11:11, Tom Lane wrote:
>> What "let result be stringified" behavior are you thinking of,
>> exactly? AFAICS there's not sensitivity to timezone unless you
>> use the _tz variant, otherwise it just regurgitates the input.
> There is stringificatio
On Sep 11, 2024, at 11:11, Tom Lane wrote:
> What "let result be stringified" behavior are you thinking of,
> exactly? AFAICS there's not sensitivity to timezone unless you
> use the _tz variant, otherwise it just regurgitates the input.
There is stringification of a time, date, or timestamp va
"David E. Wheeler" writes:
> I wonder, then, whether .string() should be modified to use the ISO format in
> UTC, and therefore be immutable. That’s the format you get if you omit
> .string() and let result be stringified from a date/time/timestamp.
What "let result be stringified" behavior are
On Sep 11, 2024, at 10:11, Tom Lane wrote:
> [ looks... ] Hmm, it looks like jsonb_path_exists_tz is marked
> stable while jsonb_path_exists is claimed to be immutable.
> So yeah, there's a problem here. I'm not 100% convinced that
> jsonb_path_exists was truly immutable before, but for sure it
Peter Eisentraut writes:
> What I'm concerned about is that this makes the behavior of JSON_QUERY
> non-immutable. Maybe there are other reasons for it to be
> non-immutable, in which case this isn't important. But it might be
> worth avoiding that?
Fair point, but haven't we already bit tha
On 10.09.24 22:16, Tom Lane wrote:
Peter Eisentraut writes:
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?
Hmm ... but does the standard precisely define the output
On Sep 10, 2024, at 16:17, Tom Lane wrote:
> Not as things stand. If we adopt Peter's nearby position that
> the current behavior is actually buggy, then probably back-patching
> a corrected version would be worthwhile as a part of fixing it.
Oh, I see now that my reply to him points out the sa
On Sep 10, 2024, at 16:10, Peter Eisentraut wrote:
> 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?
Does that also apply to `datetime(template)`, where it uses t
"David E. Wheeler" writes:
> On Sep 10, 2024, at 14:51, Tom Lane wrote:
>> Pushed with a little additional polishing.
> Thank you! Do you think it’d be worthwhile to back port to 17?
Not as things stand. If we adopt Peter's nearby position that
the current behavior is actually buggy, then prob
Peter Eisentraut writes:
> 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?
Hmm ... but does the standard precisely define the output format?
Since these conversio
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
On Sep 10, 2024, at 14:51, Tom Lane 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
>
"David E. Wheeler" writes:
> Rebase on 47c9803. I also changed the commitfest item[1] to “ready for
> committer”, since jian reviewed it, though I couldn’t see a way to add jian
> as a reviewer in the app. Hope that makes sense.
Pushed with a little additional polishing.
I thought the best way
On Jul 19, 2024, at 10:22, David E. Wheeler wrote:
>
> Here’s a rebase on 5784a49. I also updated the commitfest item[1] to link to
> a new pull request[2], since I seem to have turned the other one into the tz
> conversion bug fix.
>
> [1]: https://commitfest.postgresql.org/49/5101/
> [2]: ht
On Jul 9, 2024, at 10:45, David E. Wheeler wrote:
>> one tiny complaint would be maybe we need `reset datestyle`.
>
> That’s fair. Done.
Here’s a rebase on 5784a49. I also updated the commitfest item[1] to link to a
new pull request[2], since I seem to have turned the other one into the tz
co
On Jul 9, 2024, at 10:35, jian he wrote:
> one tiny complaint would be maybe we need `reset datestyle`.
That’s fair. Done.
D
v2-0001-Document-impact-of-datestyle-on-jsonpath-string.patch
Description: Binary data
On Thu, Jul 4, 2024 at 10:45 PM David E. Wheeler wrote:
>
> On Jul 4, 2024, at 04:28, jian he wrote:
>
> > Do you need to reset the datestyle?
>
> Wouldn’t hurt but it’s not necessary, no. It’s set only for the execution of
> this file, and there are no more calls that rely on it.
>
> > also the
On Jul 4, 2024, at 04:28, jian he wrote:
> Do you need to reset the datestyle?
Wouldn’t hurt but it’s not necessary, no. It’s set only for the execution of
this file, and there are no more calls that rely on it.
> also the above query is time zone sensitive, maybe the time zone is
> set in ano
On Wed, Jul 3, 2024 at 12:51 AM David E. Wheeler wrote:
>
> Hackers,
>
> In fuzing around trying to work out what’s going on with the formatting of
> timestamptz values cast by the timestamp_tz() jsonpath method[1], I noticed
> that the formatting of the string() method applied to date and time
Hackers,
In fuzing around trying to work out what’s going on with the formatting of
timestamptz values cast by the timestamp_tz() jsonpath method[1], I noticed
that the formatting of the string() method applied to date and time objects was
not fully tested, or how the output is determined by th
29 matches
Mail list logo
