[1]: https://commitfest.postgresql.org/patch/5270/
v9-0001-Rename-jsonpath-method-arg-tokens.patch
Description: Binary data
v9-0002-Add-additional-jsonpath-string-methods.patch
Description: Binary data
signature.asc
Description: Message signed with OpenPGP
On Jun 3, 2025, at 15:10, David E. Wheeler wrote:
>> https://github.com/theory/postgres/pull/12
>
> Found a little more unnecessary code to remove. Updated patches attached.
And these should fix the CI failure. I also ran pgindent.
Best,
David
v8-0001-Rename-jsonpat
On Jun 3, 2025, at 15:02, David E. Wheeler wrote:
> Patches attached, GitHub PR here:
>
> https://github.com/theory/postgres/pull/12
Found a little more unnecessary code to remove. Updated patches attached.
Best,
David
v7-0001-Rename-jsonpath-method-arg-tokens.patch
Descriptio
implified the grammar and fixed the
other issues I identified in my original review. Note that there are two
commits, now:
`v6-0001-Rename-jsonpath-method-arg-tokens.patch` Renames some of the symbols
in the jsonpath grammar so that they’re less generic (`csv*`) and more specific
to their conte
On May 25, 2025, at 00:16, Florents Tselai wrote:
> The most important problem in jsonpath_scan.l now is the fact that I broke
> the alphabetical ordering of keywords in v2 ,
> and you followed that too.
Oh. They have been organized by length; I didn’t notice they were also
alphabetical.
> Bu
he `method_args`
> union. Is there some reason that the existing `left` and `right` fields
> wouldn't work?
The left-right ended-up being more of a brain teaser to work with in
jsonpath_exec.
Until before these methods, the opt_datetime_template was the only argument
passed in existing js
On May 24, 2025, at 17:55, David E. Wheeler wrote:
> And now I see my patch broke the grammar because I left some of my fiddling
> in there. Apologies. Here’s an updated patch with the updated keyword map,
> too.
No, really :sigh:
D
v5-0001-Add-additional-jsonpath-string-meth
ome of my fiddling in
there. Apologies. Here’s an updated patch with the updated keyword map, too.
Best,
David
v4-0001-Add-additional-jsonpath-string-methods.patch
Description: Binary data
signature.asc
Description: Message signed with OpenPGP
On May 24, 2025, at 17:39, David E. Wheeler wrote:
> I’ve attached a new patch with docs.
Oh, and I forgot to mention, src/backend/utils/adt/jsonpath_scan.l looks like
it has a ton of duplication in it. Shouldn’t it just add the new keywords,
something like:
```
@@ -415,6 +415,11 @@ static co
{ $$ =
makeItemString(&$1); }
| VARIABLE_P{ $$ =
makeItemVariable(&$1); }
;
```
split_part() does not support a negative n value:
```
postgres=# select split_part('abc,def,ghi,jkl', ',',
> On 24 May 2025, at 7:08 PM, David E. Wheeler wrote:
>
> On May 23, 2025, at 13:52, Tom Lane wrote:
>
>>> I assume you mean that they’re set at initdb time, so there’s no mutability
>>> concern?
>>
>> Yeah, I think Peter's right and I'm wrong. Obviously this ties into
>> our philosophical
On May 23, 2025, at 13:52, Tom Lane wrote:
>> I assume you mean that they’re set at initdb time, so there’s no mutability
>> concern?
>
> Yeah, I think Peter's right and I'm wrong. Obviously this ties into
> our philosophical debate about how immutable is immutable. But as
> long as the func
Florents Tselai writes:
> On 22 May 2025, at 11:56 PM, Peter Eisentraut wrote:
>> I don't understand how this discussion got to the conclusion that functions
>> that depend on the locale cannot be immutable. Note that the top-level
>> functions lower, upper, and initcap themselves are immutabl
> On 22 May 2025, at 11:56 PM, Peter Eisentraut wrote:
>
> On 09.05.25 21:50, Robert Haas wrote:
>> I always struggle a bit to remember our policy on these issues -- to
>> the best of my knowledge, we haven't documented it anywhere, and I
>> think we probably should. I believe the way it works
On Thu, May 22, 2025 at 4:56 PM Peter Eisentraut wrote:
> I don't understand how this discussion got to the conclusion that
> functions that depend on the locale cannot be immutable. Note that the
> top-level functions lower, upper, and initcap themselves are immutable.
Oh, well that was what To
On 09.05.25 21:50, Robert Haas wrote:
I always struggle a bit to remember our policy on these issues -- to
the best of my knowledge, we haven't documented it anywhere, and I
think we probably should. I believe the way it works is that whenever
a function depends on the operating system's timestam
On May 22, 2025, at 12:38, Florents Tselai wrote:
> In my experience timestamp related stuff from jsonb documents end up in a
> generated column,
> and are indexed & queried there.
Have you seen this in the wild using the _tz functions? I wouldn’t think they
were indexable, given the volatilit
clutter, but if the consensus is that
> the clutter doesn't matter, fair enough.
>
It depends really on how much future work we expect in adding more methods in
jsonpath.
I think there’s a lot of potential there, but that’s a guess really.
On David’s point about popularity:
In my experie
On Wed, May 21, 2025 at 2:31 PM Tom Lane wrote:
> Having said that, what's wrong with inventing some improved function
> names and never removing the old ones?
I don't particularly like the clutter, but if the consensus is that
the clutter doesn't matter, fair enough.
--
Robert Haas
EDB: http:/
"David E. Wheeler" writes:
> On May 21, 2025, at 14:06, Robert Haas wrote:
>> If we want to go this route, maybe we should do
>> something like:
>> ...
>> 5. Still get complaints.
> Complainers gonna complain.
Yeah. I do not see the point of that amount of effort.
> Any idea how widespread th
On May 21, 2025, at 14:06, Robert Haas wrote:
> No, that wouldn't be too much work, but the issue is that people will
> keep using the _tz versions and when we eventually try to remove them
> those people will complain no matter how prominent we make the
> deprecation notice. If we want to go thi
On Tue, May 13, 2025 at 11:00 PM David E. Wheeler wrote:
> On May 13, 2025, at 16:24, Florents Tselai wrote:
> > As Robert said—and I agree—renaming the existing _tz family would be more
> > trouble than it’s worth, given the need for deprecations, migration paths,
> > etc. If we were designing
u may be right.
Especially if more people are interested in adding even more methods there.
Here’s a patch just merging the latest changes in the jsonpath tooling;
no substantial changes to v1; mainly for CFbot to pick this up.
v2-0001-Rebase-latest-changes.-jsonpath_scan.l-white-spac.patch
Description: Binary data
On May 13, 2025, at 16:24, Florents Tselai wrote:
> As Robert said—and I agree—renaming the existing _tz family would be more
> trouble than it’s worth, given the need for deprecations, migration paths,
> etc. If we were designing this today, suffixes like _stable or _volatile
> might have bee
re not going to add another json_path_exists_*
> function for every potentially immutable JSONPath function. But I take your
> point that it could be generalized for *any* mutable function. In which case
> maybe it should be renamed?
>
> Best,
>
> David
>
We discussed this a
7;m not sure I understand why it matters that there are multiple
> sources of mutability here. Maybe I'm missing a piece of the puzzle
> here.
I read that to mean “we’re not going to add another json_path_exists_* function
for every potentially immutable JSONPath function. But I tak
On Wed, Mar 5, 2025 at 2:30 PM Florents Tselai
wrote:
> I was thinking about taking another stab at this.
> Would someone more versed in the inner workings of jsonpath like to weigh in
> on the immutability wrt locale?
I'm not sure the issues with immutability here are particula
On Thu, Sep 26, 2024 at 1:55 PM Alexander Korotkov
wrote:
> On Thu, Sep 26, 2024 at 12:04 AM Tom Lane wrote:
> > Florents Tselai writes:
> > > This patch is a follow-up and generalization to [0].
> > > It adds the following jsonpath methods: lower, upper, initcap,
> On 27 Sep 2024, at 12:45 PM, David E. Wheeler wrote:
>
> On Sep 26, 2024, at 13:59, Florents Tselai wrote:
>
>> Speaking of extensible: the jsonpath standard does mention function
>> extensions [1] ,
>> so it looks like we're covered by the standard,
On Sep 26, 2024, at 13:59, Florents Tselai wrote:
> Speaking of extensible: the jsonpath standard does mention function
> extensions [1] ,
> so it looks like we're covered by the standard, and the mutability aspect is
> an implementation detail. No?
That’s not the standard
On Thu, Sep 26, 2024 at 1:55 PM Alexander Korotkov
wrote:
> On Thu, Sep 26, 2024 at 12:04 AM Tom Lane wrote:
> > Florents Tselai writes:
> > > This patch is a follow-up and generalization to [0].
> > > It adds the following jsonpath methods: lower, upper, initcap,
Hi, Florents!
On Wed, Sep 25, 2024 at 9:18 PM Florents Tselai
wrote:
> This patch is a follow-up and generalization to [0].
>
> It adds the following jsonpath methods: lower, upper, initcap, l/r/btrim,
> replace, split_part.
>
> It makes jsonpath able to support expr
On Thu, Sep 26, 2024 at 12:04 AM Tom Lane wrote:
> Florents Tselai writes:
> > This patch is a follow-up and generalization to [0].
> > It adds the following jsonpath methods: lower, upper, initcap, l/r/btrim,
> > replace, split_part.
>
> How are you going to deal wi
Florents Tselai writes:
> This patch is a follow-up and generalization to [0].
> It adds the following jsonpath methods: lower, upper, initcap, l/r/btrim,
> replace, split_part.
How are you going to deal with the fact that this makes jsonpath
operations not guaranteed immutable? (S
Hello hackers,
This patch is a follow-up and generalization to [0].
It adds the following jsonpath methods: lower, upper, initcap, l/r/btrim,
replace, split_part.
It makes jsonpath able to support expressions like these:
select jsonb_path_query('" hElLo WorlD "',
.
One has to create a whole new scanner, grammar etc.
Yeah, it got me thinking about the RFC-9535 JSONPath "Function Extension"
feature[1], which allows users to add functions. Would be cool to have a
way to register jsonpath functions somehow, but I would imagine it’d need
quit
etc.
Yeah, it got me thinking about the RFC-9535 JSONPath "Function
Extension" feature[1], which allows users to add functions. Would be
cool to have a way to register jsonpath functions somehow, but I
would imagine it’d need quite a bit of specification similar to
RFC-9535. Wouldn’
ks.
>>> One has to create a whole new scanner, grammar etc.
>> Yeah, it got me thinking about the RFC-9535 JSONPath "Function Extension"
>> feature[1], which allows users to add functions. Would be cool to have a way
>> to register jsonpath functions somehow,
JSONPath "Function Extension"
feature[1], which allows users to add functions. Would be cool to have a way to register
jsonpath functions somehow, but I would imagine it’d need quite a bit of specification
similar to RFC-9535. Wouldn’t surprise me to see something like that appear i
On Sep 17, 2024, at 15:03, Florents Tselai wrote:
> Fallback scenario: make this an extension, but in a first pass I didn’t find
> any convenient hooks.
> One has to create a whole new scanner, grammar etc.
Yeah, it got me thinking about the RFC-9535 JSONPath "Function Extensi
k-and-forth-parentheses-fu I do,
The easier my life is.
From a PG gatekeeping it’s a more complicated issue.
It’s not part of the spec,
But I think the jsonb infrastructure in PG is really powerful already and we
can built on it,
And can evolve into a superset DSL of jsonpath.
For example, a
pec?
> As a future note:
> It’s worth noting that both this newly added jspItem and other ones like
> (jpiDecimal, jpiString)
> use jspGetRightArg and jspGetLeftArg.
> left and right can be confusing if more complex methods are added in the
> future.
> i.e. jsonpath methods
, jpiString)use jspGetRightArg and jspGetLeftArg.left and right can be confusing if more complex methods are added in the future.i.e. jsonpath methods with nargs>=3 .I was wondering if we’d like something like JSP_GETARG(n)GitHub PR in case you prefer it’s UI https://github.com/Florents-Tse
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
Hi,When working with jsonb/jsonpath, I’ve always wanted more fluent string operations for data cleaning.Ideally, chaining text processing methods together.Here’s a draft patch that adds a string replace method.It works like thisselect jsonb_path_query('"hello world"', &#x
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 latte
o verify that datestyle *doesn't* affect it.
Looks good. Although…
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
regards, tom lane
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 1bde4091ca..aa1ac2c4fe 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -18017,16 +18017,15 @@ ERROR: jsonpath member accessor can only be applied to an object
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
mpact-of-datestyle-on-jsonpath-string.patch
Description: Binary data
On Jul 30, 2024, at 07:59, Andrew Dunstan wrote:
> I have pushed this.
Thank you, Andrew!
D
On 2024-07-22 Mo 3:12 AM, Jeevan Chalke wrote:
On Fri, Jul 19, 2024 at 7:35 PM David E. Wheeler
wrote:
On Jul 10, 2024, at 11:19, David E. Wheeler
wrote:
> Oh, and the time and date were wrong, too, because I blindly
used the same conversion for dates as for timestamps. F
On Jul 22, 2024, at 03:12, Jeevan Chalke wrote:
> I agree with David that we need to set the tz explicitly as the JsonbValue
> struct maintains that separately.
>
> However, in the attached version, I have added some comments and also, fixed
> some indentation.
Thank you for the review. I cha
On Fri, Jul 19, 2024 at 7:35 PM David E. Wheeler
wrote:
> On Jul 10, 2024, at 11:19, David E. Wheeler wrote:
>
> > Oh, and the time and date were wrong, too, because I blindly used the
> same conversion for dates as for timestamps. Fixed in v2.
> >
> > PR: https://github.com/theory/postgres/pull
On Jul 21, 2024, at 20:54, Michael Paquier wrote:
> What I mean is that the main regression test suite did not complain on
> your original patch posted here:
> https://www.postgresql.org/message-id/A95346F9-6147-46E0-809E-532A485D71D6%40justatheory.com
>
> But the new tests showed a difference,
On Fri, Jul 19, 2024 at 09:49:50AM -0400, David E. Wheeler wrote:
>> It was fun to see that HEAD was silenced with the first patch of this
>> thread that tweaked the behavior with arrays.
>
> Uh, what? Sorry I don’t follow.
What I mean is that the main regression test suite did not complain on
yo
into the tz
conversion bug fix.
Best,
David
[1]: https://commitfest.postgresql.org/49/5101/
[2]: https://github.com/theory/postgres/pull/8
v3-0001-Document-impact-of-datestyle-on-jsonpath-string.patch
Description: Binary data
On Jul 10, 2024, at 11:19, David E. Wheeler wrote:
> Oh, and the time and date were wrong, too, because I blindly used the same
> conversion for dates as for timestamps. Fixed in v2.
>
> PR: https://github.com/theory/postgres/pull/7
> CF: https://commitfest.postgresql.org/49/5119/
Rebase on 57
On Jul 19, 2024, at 01:42, Michael Paquier wrote:
> Sorry for the delay. Finally came back to it, and applied the tests.
> Thanks!
Awesome, thank you!
> It was fun to see that HEAD was silenced with the first patch of this
> thread that tweaked the behavior with arrays.
Uh, what? Sorry I don’
On Mon, Jul 15, 2024 at 10:29:32AM -0400, David E. Wheeler wrote:
> It’s here:
>
> https://commitfest.postgresql.org/48/5017/
Sorry for the delay. Finally came back to it, and applied the tests.
Thanks!
It was fun to see that HEAD was silenced with the first patch of this
thread that tweaked
On Jul 15, 2024, at 07:07, Stepan Neretin wrote:
> Hi! Looks good to me now! Please, register a patch in CF.
> Best regards, Stepan Neretin.
It’s here:
https://commitfest.postgresql.org/48/5017/
Best,
David
On Mon, Jul 8, 2024 at 11:09 PM David E. Wheeler
wrote:
> On Jun 27, 2024, at 04:17, Michael Paquier wrote:
>
> > The tests of jsonb_jsonpath.sql include a lot of patterns for @? and
> > jsonb_path_query with the lax and strict modes, so shouldn't these
> > additions be grouped closer to the exi
On Jul 10, 2024, at 10:54, David E. Wheeler wrote:
> So it should be -7, not -8. Not sure where to tell it to pay proper attention
> to daylight savings time.
Oh, and the time and date were wrong, too, because I blindly used the same
conversion for dates as for timestamps. Fixed in v2.
PR: ht
On Jul 10, 2024, at 10:33, David E. Wheeler wrote:
> Yeah I don’t know either, but now at least it’s consistent. I’ve attached a
> patch to fix it.
Actually I think there’s a subtlety still missing here:
@@ -2914,7 +2914,7 @@ HINT: Use *_tz() function for time zone support.
select jsonb_path
On Jul 10, 2024, at 10:33, David E. Wheeler wrote:
> Yeah I don’t know either, but now at least it’s consistent. I’ve attached a
> patch to fix it.
>
> Ideally, I think, we wouldn’t convert the value and determine the offset
> twice, but teach date_timestamptz and timestamp_timestamptz (or
>
On Jul 10, 2024, at 01:48, Junwang Zhao wrote:
> I apply your patch with some minor change(to make the server not crash):
Oh, thank you! Kicking myself for not catching the obvious.
> It now gives the local tz:
>
> [local] postgres@postgres:5432-54960=# set time zone 'America/New_York';
> SET
On Tue, Jul 9, 2024 at 11:38 PM David E. Wheeler wrote:
>
> On Jul 9, 2024, at 11:08, Junwang Zhao wrote:
>
> > In JsonbValue.val.datatime, there is a tz field, I think that's where
> > the offset stored, it is 18000 in the first example
> >
> > struct
> > {
> > Datum value;
> > Oid typid;
> > in
On Jul 9, 2024, at 11:08, Junwang Zhao wrote:
> In JsonbValue.val.datatime, there is a tz field, I think that's where
> the offset stored, it is 18000 in the first example
>
> struct
> {
> Datum value;
> Oid typid;
> int32 typmod;
> int tz; /* Numeric time zone, in seconds, for
> * Time
On Tue, Jul 9, 2024 at 10:22 PM David E. Wheeler wrote:
>
> On Jul 9, 2024, at 10:07, David E. Wheeler wrote:
>
> > So perhaps I had things reversed before. Maybe it’s actually doing the
> > right then when it converts a timestamp to a timestamptz, but not when it
> > the input contains an offs
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 9, 2024, at 10:07, David E. Wheeler wrote:
> So perhaps I had things reversed before. Maybe it’s actually doing the right
> then when it converts a timestamp to a timestamptz, but not when it the input
> contains an offset, as in your example.
To clarify, there’s an inconsistency in the
> On Jul 8, 2024, at 21:44, Junwang Zhao wrote:
>
> # select jsonb_path_query_tz('"2024-08-15 12:34:56-05"', '$.timestamp_tz()');
>
> Do you also expect this to show the time in America/New_York?
>
> This is what I get:
>
> [local] postgres@postgres:5432-28176=# select
> jsonb_path_query_tz
as expected. But look at
> the output from a path query:
>
> david=# select jsonb_path_query_tz('"2023-08-15"', '$.timestamp_tz()');
> jsonb_path_query_tz
> -
> "2023-08-15T04:00:00+00:00"
>
> It’s using
> - "2023-08-15T12:34:56+00:00"
> + "2023-08-15T12:34:56+10:00"
> (1 row)
>
> select jsonb_path_query('"10-03-2017 12:34"', '$.datetime("dd-mm-
> HH24:MI")');
> ```
FWIW I fixed this issue
f the file?
I’ve moved them closer to other tests for unwrapping behavior in the attached
updated and rebased v3 patch.
Best,
David
v3-0001-Add-tests-for-jsonpath-.-on-arrays.patch
Description: Binary data
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 applie
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
On Jul 1, 2024, at 11:02, David E. Wheeler wrote:
> Anyway, should the output of timestamptz JSONB values be made more
> consistent? I’m happy to make a patch to do so, but could use a hand figuring
> out where the behavior varies.
I think if the formatting was more consistent, the test output
ot;
It’s using UTC for the display output! Shouldn’t it be using America/New_York?
Note that I’m comparing a cast from date to timestamptz because that’s how the
jsonpath parsing works[1]: it ultimately uses
date2timestamptz_opt_overflow()[2] to make the conversion, which appears to set
the offse
On Jun 27, 2024, at 04:17, Michael Paquier wrote:
> The tests of jsonb_jsonpath.sql include a lot of patterns for @? and
> jsonb_path_query with the lax and strict modes, so shouldn't these
> additions be grouped closer to the existing tests rather than added at
> the end of the file?
I think y
On Thu, Jun 27, 2024 at 11:53:14AM +0700, Stepan Neretin wrote:
> HI! Now it looks good for me.
The tests of jsonb_jsonpath.sql include a lot of patterns for @? and
jsonb_path_query with the lax and strict modes, so shouldn't these
additions be grouped closer to the existing tests rather than adde
1 - 100 of 483 matches
Mail list logo
