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 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 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: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
On Mon, Jul 1, 2024 at 11:02 PM David E. Wheeler wrote:
>
> Hackers,
>
> There’s an odd difference in the behavior of timestamp_tz() outputs. Running
> with America/New_York as my TZ, it looks fine for a full timestamptz,
> identical to how casting the types directly works:
>
> david=# set time
On Jul 2, 2024, at 10:53, David E. Wheeler wrote:
> ``` patch
> --- a/src/test/regress/expected/jsonb_jsonpath.out
> +++ b/src/test/regress/expected/jsonb_jsonpath.out
> @@ -2914,7 +2914,7 @@ HINT: Use *_tz() function for time zone support.
> select jsonb_path_query_tz('"2023-08-15"', '$.timesta
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
On 06/20/24 10:54, David E. Wheeler wrote:
> Still not sure about `24:00:00` as a time, though. I presume the jsonpath
> standard disallows it.
In 9075-2 9.46 "SQL/JSON path language: syntax and semantics", the behavior
of the .time() and .time_tz() and similar item methods defers to the
behavior
On Apr 29, 2024, at 20:45, David E. Wheeler wrote:
> I noticed that the jsonpath date/time functions (.time() and timestamp(), et
> al.) don’t support some valid but special-case PostgreSQL values, notably
> `infinity`, `-infinity`, and, for times, '24:00:00`:
Looking at ECMA-404[1], “The JSON
On 06/18/24 08:30, Peter Eisentraut wrote:
> Are you saying we shouldn't allow .boolean() to be called on a JSON number?
>
> I would concur that that's what the spec says.
Or, if we want to extend the spec and allow .boolean() on a JSON number,
should it just check that the number is nonzero or z
On 18.06.24 04:17, Chapman Flack wrote:
On 06/17/24 19:17, David E. Wheeler wrote:
[1]:
https://github.com/postgres/postgres/blob/82ed67a/src/backend/utils/adt/jsonpath_exec.c#L2058-L2059
Huh, I just saw something peculiar, skimming through the code:
https://github.com/postgres/postgres/blob
On 06/17/24 19:17, David E. Wheeler wrote:
> [1]:
> https://github.com/postgres/postgres/blob/82ed67a/src/backend/utils/adt/jsonpath_exec.c#L2058-L2059
Huh, I just saw something peculiar, skimming through the code:
https://github.com/postgres/postgres/blob/82ed67a/src/backend/utils/adt/jsonpath_
On Jun 17, 2024, at 6:44 PM, Chapman Flack wrote:
> The current implementation seems to have made each of our
> s responsible for swallowing its own errors, which
> is one perfectly cromulent way to satisfy the SQL standard behavior saying
> all errors within a should be swallowed.
Naw, execute
On 06/17/24 18:14, David E. Wheeler wrote:
> So I think that’s the key: There’s not a difference between the behavior of
> `like_regex` and `starts with` vs other predicate expressions.
The current implementation seems to have made each of our
s responsible for swallowing its own errors, which
is
On Jun 16, 2024, at 11:52, David E. Wheeler wrote:
> I think that’s how it should be; I prefer that it raises errors by default
> but you can silence them:
>
> david=# select jsonb_path_query(target => '{"x": "hi"}', path =>
> '$.integer()', silent => false);
> ERROR: jsonpath item method .in
On Jun 15, 2024, at 12:23, Chapman Flack wrote:
> I see. Yes, that documentation now says "predicate check expressions return
> the single three-valued result of the predicate: true, false, or unknown".
It has been there since jsonpath was introduced in v12[1]:
> A path expression can be a Bool
On 06/15/24 10:47, David E. Wheeler wrote:
> these are predicate check expressions, supported and documented
> as an extension to the standard since Postgres 12[1].
> ...
> [1]:
> https://www.postgresql.org/docs/devel/functions-json.html#FUNCTIONS-SQLJSON-CHECK-EXPRESSIONS
I see. Yes, that docume
On Jun 14, 2024, at 22:29, Chapman Flack wrote:
> So I should go look at our code to see what grammar we've implemented,
> exactly. It is beginning to seem as if we have simply added
> as another choice for an expression, not restricted
> to only appearing in a filter. If so, and we add document
On 06/14/24 22:29, Chapman Flack wrote:
> So I should go look at our code to see what grammar we've implemented,
> exactly. It is beginning to seem as if we have simply added
> as another choice for an expression, not restricted
> to only appearing in a filter. If so, and we add documentation abou
On 06/14/24 12:21, David E. Wheeler wrote:
> I noticed that neither `regex_like` nor `starts with`, the jsonpath
> operators, raise an error when the operand is not a string (or array of
> strings):
>
> david=# select jsonb_path_query('true', '$ like_regex "^hi"');
> jsonb_path_query
> ---
On Jun 13, 2024, at 22:31, Chapman Flack wrote:
> It's baked right into the standard grammar: || can only have a
> on its right and a
> on its left.
>
> && can only have a on its right and a
> on its left.
Wow.
> The case for ! is even more limiting: it can't be applied to anything
> but
On 06/13/24 22:16, David E. Wheeler wrote:
> But even inside filters I don’t understand why &&, ||, at least,
> currently only work if their operands are predicate expressions.
> Seems weird; and your notes above suggest that rule applies only to !,
> which makes slightly more sense.
It's baked ri
On Jun 13, 2024, at 21:58, Chapman Flack wrote:
david=# select jsonb_path_query('1', '$ >= 1');
>>>
>>> Good point. I can't either. No way I can see to parse that as
>>> a .
>>
>> Whether we note it as non-standard or not is an open question then, but it
>> does work and opens up a documen
On Thursday, June 13, 2024, Chapman Flack wrote:
> On 06/13/24 21:46, David G. Johnston wrote:
> >>> david=# select jsonb_path_query('1', '$ >= 1');
> >>
> >> Good point. I can't either. No way I can see to parse that as
> >> a .
> >
> > Whether we note it as non-standard or not is an open questi
On 06/13/24 21:46, David G. Johnston wrote:
>>> david=# select jsonb_path_query('1', '$ >= 1');
>>
>> Good point. I can't either. No way I can see to parse that as
>> a .
>
> Whether we note it as non-standard or not is an open question then, but it
> does work and opens up a documentation questio
On Thursday, June 13, 2024, Chapman Flack wrote:
> On 06/13/24 21:24, David G. Johnston wrote:
> > I'm content that the operators in the 'filter operators' table need to be
> > within filter but then I cannot reconcile why this example worked:
> >
> > david=# select jsonb_path_query('1', '$ >= 1'
On 06/13/24 21:24, David G. Johnston wrote:
> I'm content that the operators in the 'filter operators' table need to be
> within filter but then I cannot reconcile why this example worked:
>
> david=# select jsonb_path_query('1', '$ >= 1');
Good point. I can't either. No way I can see to parse th
On Thu, Jun 13, 2024 at 6:10 PM Chapman Flack wrote:
> On 06/13/24 16:43, David E. Wheeler wrote:
> > Paging Mr. Eisentraut!
>
> I'm not Mr. Eisentraut, but I have at last talked my way into some
> access to the standard, so ...
>
> Note 487 emphasizes that JSON path predicates "are not expressio
On 06/13/24 16:43, David E. Wheeler wrote:
> Paging Mr. Eisentraut!
I'm not Mr. Eisentraut, but I have at last talked my way into some
access to the standard, so ...
Note 487 emphasizes that JSON path predicates "are not expressions;
instead they form a separate language that can only be invoked
On 2024-06-13 Th 11:37, David E. Wheeler wrote:
On Jun 13, 2024, at 11:32, David E. Wheeler wrote:
Should && and || not also work on scalar operands?
I see the same issue for unary !, too:
What does the spec say about these? What do other implementations do?
cheers
andrew
--
Andrew D
On Jun 13, 2024, at 3:33 PM, Andrew Dunstan wrote:
> What does the spec say about these? What do other implementations do?
Paging Mr. Eisentraut!
:-)
D
On Jun 13, 2024, at 11:32, David E. Wheeler wrote:
> Should && and || not also work on scalar operands?
I see the same issue for unary !, too:
david=# select jsonb_path_query('true', '!$');
ERROR: syntax error at or near "$" of jsonpath input
LINE 1: select jsonb_path_query('true', '!$');
Hi hackers!
Could the 1 byte from the JsonPath header be used to store version?
Or how many bits from the header could be used for the version value?
On Mon, Mar 27, 2023 at 12:54 PM Nikita Malakhov wrote:
> Hi hackers!
>
> I've got a question on the JsonPath header - currently the header size
These syntax extensions would make the jsonpath syntax a super powerful query
language capable of most nosql workloads people would have. Especially querying
jsonpath with a variable key to look for is a sorely missed feature from the
language. I would be open to reviewing the patches if need be
On Jan 30, 2023, at 08:17, Filipp Krylov wrote:
>> My question: Are there plans to support square bracket syntax for JSON
>> object field name strings like this? Or to update to follow the standard as
>> it’s finalized?
>
> This syntax is a part of "jsonpath syntax extensions" patchset:
> htt
Hi David,
On 2022-11-10 21:55, David E. Wheeler wrote:
My question: Are there plans to support square bracket syntax for JSON
object field name strings like this? Or to update to follow the
standard as it’s finalized?
This syntax is a part of "jsonpath syntax extensions" patchset:
https://ww
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
Hi,
Ok, we'll rebase it onto actual master for the next iteration.
Thank you!
On Thu, Mar 31, 2022 at 10:17 PM Greg Stark wrote:
> Well I still think this would be a good candidate to get reviewed.
>
> But it currently needs a rebase and it's the last day of the CF so I
> guess it'll get moved f
Well I still think this would be a good candidate to get reviewed.
But it currently needs a rebase and it's the last day of the CF so I
guess it'll get moved forward again. I don't think "returned with
feedback" is helpful given there's been basically no feedback :(
Hi,
On 2022-03-21 21:09, Greg Stark wrote:
This patch seems to be getting ignored. Like David I'm a bit puzzled
because it doesn't seem like an especially obscure or difficult patch
to review. Yet it's been multiple years without even a superficial
"does it meet the coding requirements" review l
Op 21-03-2022 om 21:13 schreef Greg Stark:
Hm. Actually... These changes were split off from the JSON_TABLE
patches? Are they still separate or have they been merged into those
other patches since? I see the JSON_TABLE thread is getting more
comments do those reviews include these patches?
T
Hm. Actually... These changes were split off from the JSON_TABLE
patches? Are they still separate or have they been merged into those
other patches since? I see the JSON_TABLE thread is getting more
comments do those reviews include these patches?
On Mon, 21 Mar 2022 at 16:09, Greg Stark wrote:
>
This patch seems to be getting ignored. Like David I'm a bit puzzled
because it doesn't seem like an especially obscure or difficult patch
to review. Yet it's been multiple years without even a superficial
"does it meet the coding requirements" review let alone a design
review.
Can we get a volunt
On 3/3/21 9:44 AM, David Steele wrote:
On 3/4/20 3:18 PM, Nikita Glukhov wrote:
On 04.03.2020 19:13, David Steele wrote:
On 2/27/20 10:57 AM, Nikita Glukhov wrote:
Attached patches implement several useful jsonpath syntax extensions.
I already published them two years ago in the original SQL/
On 3/4/20 3:18 PM, Nikita Glukhov wrote:
On 04.03.2020 19:13, David Steele wrote:
On 2/27/20 10:57 AM, Nikita Glukhov wrote:
Attached patches implement several useful jsonpath syntax extensions.
I already published them two years ago in the original SQL/JSON thread,
but then after creation of
Alexander Korotkov writes:
> The patch, which clarifies this situation in the docs is attached.
> I'm going to push it if no objections.
+1, but the English in this seems a bit shaky. Perhaps more
like the attached?
regards, tom lane
diff --git a/doc/src/sgml/func.sgml
On Mon, Jan 25, 2021 at 6:33 PM Alexander Korotkov wrote:
> On Thu, Jan 21, 2021 at 4:35 PM Alvaro Herrera
> wrote:
> > On 2021-Jan-21, Alexander Korotkov wrote:
> >
> > > Requiring strict mode for ** is a solution, but probably too
> > > restrictive...
> > >
> > > What do you think about makin
On Thu, Jan 21, 2021 at 4:35 PM Alvaro Herrera wrote:
> On 2021-Jan-21, Alexander Korotkov wrote:
>
> > Requiring strict mode for ** is a solution, but probably too restrictive...
> >
> > What do you think about making just subsequent accessor after ** not
> > to unwrap arrays. That would be a bi
On Thu, Jan 21, 2021 at 12:38 PM Thomas Kellerer wrote:
> Alexander Korotkov schrieb am 20.01.2021 um 18:13:
> > We have a bug report which says that jsonpath ** operator behaves strangely
> > in the lax mode [1].
> That report was from me ;)
>
> Thanks for looking into it.
>
> > At first sight,
On 2021-Jan-21, Alexander Korotkov wrote:
> Requiring strict mode for ** is a solution, but probably too restrictive...
>
> What do you think about making just subsequent accessor after ** not
> to unwrap arrays. That would be a bit tricky to implement, but
> probably that would better satisfy t
Alexander Korotkov schrieb am 20.01.2021 um 18:13:
> We have a bug report which says that jsonpath ** operator behaves strangely
> in the lax mode [1].
That report was from me ;)
Thanks for looking into it.
> At first sight, we may just say that lax mode just sucks and
> counter-intuitive resul
Hi, Alvaro!
Thank you for your feedback.
On Wed, Jan 20, 2021 at 9:16 PM Alvaro Herrera wrote:
> On 2021-Jan-20, Alexander Korotkov wrote:
>
> > My proposal is to make everything after the ** operator use strict mode
> > (patch attached). I think this shouldn't be backpatched, just applied to
>
On 2021-Jan-20, Alexander Korotkov wrote:
> My proposal is to make everything after the ** operator use strict mode
> (patch attached). I think this shouldn't be backpatched, just applied to
> the v14. Other suggestions?
I think changing the mode midway through the operation is strange. What
d
Alexander Korotkov writes:
> On Thu, Jul 9, 2020 at 4:04 AM Alexander Korotkov
> wrote:
>> I understand both patches as fixes and propose to backpatch them to 12
>> if no objections.
> Both patches are pushed.
Thanks for taking care of that!
regards, tom lane
On Thu, Jul 9, 2020 at 4:04 AM Alexander Korotkov wrote:
> I understand both patches as fixes and propose to backpatch them to 12
> if no objections.
Both patches are pushed.
--
Regards,
Alexander Korotkov
On Thu, Jul 9, 2020 at 1:20 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > The patchset is attached, sorry for the delay.
>
> > The first patch improves error messages, which appears to be unclear
> > for me. If one applies .double() method to a numeric value, we
> > restrict that this nume
Alexander Korotkov writes:
> The patchset is attached, sorry for the delay.
> The first patch improves error messages, which appears to be unclear
> for me. If one applies .double() method to a numeric value, we
> restrict that this numeric value should fit to double precision type.
> If it does
On Wed, Jul 8, 2020 at 1:16 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > I'm going to push 0002 if there is no objection.
> > Regarding 0001, I think my new error messages need review.
>
> I do intend to review these, just didn't get to it yet.
OK, that you for noticing. I wouldn't push
Alexander Korotkov writes:
> I'm going to push 0002 if there is no objection.
> Regarding 0001, I think my new error messages need review.
I do intend to review these, just didn't get to it yet.
regards, tom lane
On Mon, Jul 6, 2020 at 3:19 PM Alexander Korotkov wrote:
> The patchset is attached, sorry for the delay.
>
> The first patch improves error messages, which appears to be unclear
> for me. If one applies .double() method to a numeric value, we
> restrict that this numeric value should fit to doub
On Thu, Jun 18, 2020 at 8:04 PM Alexander Korotkov
wrote:
> On Thu, Jun 18, 2020 at 7:45 PM Tom Lane wrote:
> > Alexander Korotkov writes:
> > > Thank you for your answer. I'm trying to understand your point.
> > > Standard claims that .double() method should behave the same way as
> > > CAST to
On 6/18/20 12:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 18, 2020 at 11:51 AM Oleg Bartunov
>> wrote:
>>> The problem is that we tried to find a trade-off between standard and
>>> postgres
>>> implementation, for example, in postgres CAST allows NaN and Inf, and SQL
>>> St
On Thu, Jun 18, 2020 at 7:45 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Thank you for your answer. I'm trying to understand your point.
> > Standard claims that .double() method should behave the same way as
> > CAST to double. However, standard references the standard behavior of
> > C
Alexander Korotkov writes:
> Thank you for your answer. I'm trying to understand your point.
> Standard claims that .double() method should behave the same way as
> CAST to double. However, standard references the standard behavior of
> CAST here, not behavior of your implementation of CAST. So,
On Thu, Jun 18, 2020 at 7:34 PM Alexander Korotkov
wrote:
> Thank you for your answer. I'm trying to understand your point.
> Standard claims that .double() method should behave the same way as
> CAST to double. However, standard references the standard behavior of
> CAST here, not behavior of yo
Robert Haas writes:
> On Thu, Jun 18, 2020 at 11:51 AM Oleg Bartunov
> wrote:
>> The problem is that we tried to find a trade-off between standard and
>> postgres
>> implementation, for example, in postgres CAST allows NaN and Inf, and SQL
>> Standard
>> requires .double should works as CAST
Tom,
On Thu, Jun 18, 2020 at 7:07 PM Tom Lane wrote:
> Oleg Bartunov writes:
> > The problem is that we tried to find a trade-off between standard and
> > postgres implementation, for example, in postgres CAST allows NaN and
> > Inf, and SQL Standard requires .double should works as CAST.
>
> As
On Thu, Jun 18, 2020 at 11:51 AM Oleg Bartunov wrote:
> The problem is that we tried to find a trade-off between standard and
> postgres
> implementation, for example, in postgres CAST allows NaN and Inf, and SQL
> Standard
> requires .double should works as CAST.
It seems like the right thin
Oleg Bartunov writes:
> The problem is that we tried to find a trade-off between standard and
> postgres implementation, for example, in postgres CAST allows NaN and
> Inf, and SQL Standard requires .double should works as CAST.
As I said, I think this is a fundamental misreading of the standard.
On Wed, Jun 17, 2020 at 6:33 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Thu, Jun 11, 2020 at 10:00 PM Tom Lane wrote:
> >> I don't think this is very relevant. The SQL standard has not got the
> >> concepts of Inf or NaN either (see 4.4.2 Characteristics of numbers),
> >> therefore
Alexander Korotkov writes:
> On Thu, Jun 11, 2020 at 10:00 PM Tom Lane wrote:
>> I don't think this is very relevant. The SQL standard has not got the
>> concepts of Inf or NaN either (see 4.4.2 Characteristics of numbers),
>> therefore their definition is only envisioning that a string represen
On Thu, Jun 11, 2020 at 10:00 PM Tom Lane wrote:
>
> Alexander Korotkov writes:
> > On Thu, Jun 11, 2020 at 3:45 PM Tom Lane wrote:
> >> It is entirely clear from the code, the documentation,
> >> and the relevant RFCs that JSONB does not allow NaNs as numeric
> >> values.
>
> > The JSONB itself
Alexander Korotkov writes:
> On Thu, Jun 11, 2020 at 3:45 PM Tom Lane wrote:
>> It is entirely clear from the code, the documentation,
>> and the relevant RFCs that JSONB does not allow NaNs as numeric
>> values.
> The JSONB itself doesn't store number NaNs. It stores the string "NaN".
Yeah, b
Hi Tom,
Thank you for raising this issue.
On Thu, Jun 11, 2020 at 3:45 PM Tom Lane wrote:
> Commit 72b646033 inserted this into convertJsonbScalar:
>
> break;
>
> case jbvNumeric:
> + /* replace numeric NaN with string "NaN" */
> +
On 04.03.2020 19:13, David Steele wrote:
Hi Nikita,
On 2/27/20 10:57 AM, Nikita Glukhov wrote:
Attached patches implement several useful jsonpath syntax extensions.
I already published them two years ago in the original SQL/JSON thread,
but then after creation of separate threads for SQL/JSON
Hi Nikita,
On 2/27/20 10:57 AM, Nikita Glukhov wrote:
Attached patches implement several useful jsonpath syntax extensions.
I already published them two years ago in the original SQL/JSON thread,
but then after creation of separate threads for SQL/JSON functions and
JSON_TABLE I forgot about th
On 2019-09-25 16:46, Liudmila Mantrova wrote:
> On 9/25/19 12:08 AM, Peter Eisentraut wrote:
>> On 2019-09-23 00:03, Tom Lane wrote:
>>> While we're whining about this, I find it very off-putting that
>>> the jsonpath stuff was inserted in the JSON functions section
>>> ahead of the actual JSON fun
On 9/25/19 12:08 AM, Peter Eisentraut wrote:
On 2019-09-23 00:03, Tom Lane wrote:
While we're whining about this, I find it very off-putting that
the jsonpath stuff was inserted in the JSON functions section
ahead of the actual JSON functions. I think it should have
gone after them, because it
On 2019-09-23 00:03, Tom Lane wrote:
> While we're whining about this, I find it very off-putting that
> the jsonpath stuff was inserted in the JSON functions section
> ahead of the actual JSON functions. I think it should have
> gone after them, because it feels like a barely-related interjection
Privet :D
On Mon, Sep 23, 2019 at 12:29 PM Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> Hi!
>
> On Mon, Sep 23, 2019 at 10:10 PM Steven Pousty
> wrote:
> >
> https://standards.iso.org/ittf/PubliclyAvailableStandards/c067367_ISO_IEC_TR_19075-6_2017.zip
>
> Yes, this link looks good t
Hi!
On Mon, Sep 23, 2019 at 10:10 PM Steven Pousty wrote:
> Thanks for the education on the path spec. Too bad it is in a zip doc - do
> you know of a place where it is publicly available so we can link to it?
> Perhaps there is some document or page you think would be a good reference
> read
Hey there:
Thanks for the education on the path spec. Too bad it is in a zip doc - do
you know of a place where it is publicly available so we can link to it?
Perhaps there is some document or page you think would be a good reference
read for people who want to understand more?
https://standards.is
On Mon, Sep 23, 2019 at 7:52 PM Steven Pousty wrote:
> JSON Containment, JSONPath, and Transforms are means to work with JSONB but
> not the actual datatype itself. Doc should be split into
> 1) Data type - how do declare, indexing, considerations when using it...
> 2) Ways to work with the data
JSON Containment, JSONPath, and Transforms are means to work with JSONB but
not the actual datatype itself. Doc should be split into
1) Data type - how do declare, indexing, considerations when using it...
2) Ways to work with the data type - functions, containment, JSONPath...
These can be separa
On Mon, Sep 23, 2019 at 1:03 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Sun, Sep 22, 2019 at 9:18 PM Jeff Janes wrote:
> > Currently description of jsonpath is divided between datatypes section
> > and functions and operators section. And yes, this looks cumbersome.
>
> Agreed, but
Alexander Korotkov writes:
> On Sun, Sep 22, 2019 at 9:18 PM Jeff Janes wrote:
> Currently description of jsonpath is divided between datatypes section
> and functions and operators section. And yes, this looks cumbersome.
Agreed, but ...
> I think we should move the whole description to the o
Hi!
On Sun, Sep 22, 2019 at 9:18 PM Jeff Janes wrote:
> I find the documentation in
> https://www.postgresql.org/docs/12/functions-json.html very confusing.
>
> In table 9.44 take the first entry,
>
> Example JSON
> {"x": [2.85, -14.7, -9.4]}
>
> Example Query
> + $.x.floor()
>
> Result
> 2,
On Sun, Sep 22, 2019 at 2:18 PM Jeff Janes wrote:
> I find the documentation in
> https://www.postgresql.org/docs/12/functions-json.html very confusing.
>
> In table 9.44 take the first entry,
>
> Example JSON
> {"x": [2.85, -14.7, -9.4]}
>
> Example Query
> + $.x.floor()
>
> Result
> 2, -15,
On Fri, May 17, 2019 at 6:50 AM Alexander Korotkov
wrote:
> Couple patches improving jsonpath docs are attached. The first one
> documents nesting level filter for .** accessor. The second adds to
> documentation of jsonpath array subsciption usage of expressions and
> multiple slice ranges. I'
Couple patches improving jsonpath docs are attached. The first one
documents nesting level filter for .** accessor. The second adds to
documentation of jsonpath array subsciption usage of expressions and
multiple slice ranges. I'm going to push both patches if no
objections.
--
Alexander Ko
1 - 100 of 277 matches
Mail list logo
