Hello hackers,
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`:
❯ psql
psql (17devel)
Type "help" for help.
davi
On Apr 24, 2024, at 3:22 PM, Erik Wienhold wrote:
> Thanks Peter! But what is the definition of the entire path expression?
> Perhaps something like:
>
> ::= { "." }
>
> That would imply that "$.$foo" is a valid path that accesses a variable
> member (but I guess the path evaluation is
er accessors as well when
seeing ."$varname" in the same table.
> Yes, it does, as it ties the special meaning of the dollar sign to the
> *beginning* of an expression. So it makes sense that this would be an
> error:
>
> david=# select '$.$foo'::jsonpath;
> ERROR: syntax
On Apr 24, 2024, at 05:46, Peter Eisentraut wrote:
> I have committed this patch, and backpatched it, as a bug fix, because the
> existing description was wrong. To keep the patch minimal for backpatching,
> I didn't do the conversion to a list. I'm not sure I like that anyway,
> because it
I wasn't following all the discussion to see if there is
> anything wrong with the implementation.
Yes, it does, as it ties the special meaning of the dollar sign to the
*beginning* of an expression. So it makes sense that this would be an error:
david=# select '$.$foo'::jsonpath;
ERROR:
On 18.03.24 01:09, Erik Wienhold wrote:
The error message 'syntax error at or near "$oo" of jsonpath input' for
the second case ($.f$oo), however, looks as if the scanner identifies
'$oo' as a variable instead of contiuing the scan of identifier (f$oo)
for the member accessor. Looks
On 17.03.24 20:12, Erik Wienhold wrote:
Mentioning JSON and \v in the same sentence is wrong: JavaScript allows
that escape in strings but JSON doesn't. I think the easiest is to just
replace "JSON" with "JavaScript" in that sentence to make it right. The
paragraph also already says "embedded
a commit fest.
>
> Thanks. https://commitfest.postgresql.org/48/4899/
Applies cleanly, `make -C doc/src/sgml check` runs without error. Doc
improvement welcome and much clearer than before.
> I had the same reasoning while writing my first reply but scrapped that
> part because I
ne is used here. I guess it’s being
> conservative because it might be used in one of the functions, like
> jsonb_path_exists(), to which variables might be passed.
I had the same reasoning while writing my first reply but scrapped that
part because I found it obvious: That jsonpath is parsed befor
riables might be passed.
> The error message 'syntax error at or near "$oo" of jsonpath input' for
> the second case ($.f$oo), however, looks as if the scanner identifies
> '$oo' as a variable instead of contiuing the scan of identifier (f$oo)
> for the member accessor.
Hi David,
On 2024-03-16 19:39 +0100, David E. Wheeler wrote:
> The jsonpath doc[1] has an excellent description of the format of
> strings, but for unquoted path keys, it simply says:
>
> > Member accessor that returns an object member with the specified
> > key. If the
utside double-quoted string identifiers:
david=# select '$.$foo'::jsonpath;
ERROR: syntax error at or near "$foo" of jsonpath input
LINE 1: select '$.$foo'::jsonpath;
^
david=# select '$.f$oo'::jsonpath;
ERROR: syntax error at or near "$oo" of jsonpath input
Hackers,
The jsonpath doc[1] has an excellent description of the format of strings, but
for unquoted path keys, it simply says:
> Member accessor that returns an object member with the specified key. If the
> key name matches some named variable starting with $ or does no
> >
>> > On Wed, Feb 7, 2024 at 9:13 PM jian he
>> wrote:
>> >>
>> >> On Wed, Feb 7, 2024 at 7:36 PM Jeevan Chalke
>> >> wrote:
>> >> > Added checkTimezoneIsUsedForCast() check where ever we are casting
>> timezoned to non
at 7:36 PM Jeevan Chalke
>> wrote:
>> > Added checkTimezoneIsUsedForCast() check where ever we are
casting timezoned to non-timezoned types and vice-versa.
>>
>> https://www.postgresql.org/docs/devel/functions-json.html
>> above Table 9.51. jso
:
> >> > Added checkTimezoneIsUsedForCast() check where ever we are casting
> timezoned to non-timezoned types and vice-versa.
> >>
> >> https://www.postgresql.org/docs/devel/functions-json.html
> >> above Table 9.51. jsonpath Filter Expression Elem
timezoned to non-timezoned types and vice-versa.
>>
>> https://www.postgresql.org/docs/devel/functions-json.html
>> above Table 9.51. jsonpath Filter Expression Elements, the Note
>> section, do we also need to rephrase it?
>
>
> OK. Added a line for the same.
>
ons-json.html
> above Table 9.51. jsonpath Filter Expression Elements, the Note
> section, do we also need to rephrase it?
>
OK. Added a line for the same.
Thanks
--
Jeevan Chalke
*Principal, ManagerProduct Development*
edbpostgres.com
v2-preserve-immutability.patch
Description: Binary data
On Wed, Feb 7, 2024 at 7:36 PM Jeevan Chalke
wrote:
> Added checkTimezoneIsUsedForCast() check where ever we are casting timezoned
> to non-timezoned types and vice-versa.
https://www.postgresql.org/docs/devel/functions-json.html
above Table 9.51. jsonpath Filter Expression Elements, th
On Tue, Feb 6, 2024 at 5:25 PM Andrew Dunstan wrote:
>
> On 2024-02-05 Mo 22:06, jian he wrote:
>
>
> Hi.
> this commit [0] changes immutability of jsonb_path_query,
> jsonb_path_query_first?
> If so, it may change other functions also.
>
>
Thanks for reporting Jian.
Added
On 2024-02-05 Mo 22:06, jian he wrote:
Hi.
this commit [0] changes immutability of jsonb_path_query,
jsonb_path_query_first? If so, it may change other functions also.
demo:
begin;
SET LOCAL TIME ZONE 10.5;
with cte(s) as (select jsonb '"2023-08-15 12:34:56 +05:30"')
select
Hi.
this commit [0] changes immutability of jsonb_path_query,
jsonb_path_query_first?
If so, it may change other functions also.
demo:
begin;
SET LOCAL TIME ZONE 10.5;
with cte(s) as (select jsonb '"2023-08-15 12:34:56 +05:30"')
select jsonb_path_query(s,
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 he
Hi hackers!
I've got a question on the JsonPath header - currently the header size
is 4 bytes, where there are version and mode bits. Is there somewhere
a defined size of the version part? There are some extensions working
with JsonPath, and we have some too, thus it is important how many
bits
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
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 "jsonpat
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" patchs
Greetings! Long time no see, I know. How are you, Hackers?
I notice from the docs in the Postgres JSONPath type, brackets are described as:
> • Square brackets ([]) are used for array access.
https://www.postgresql.org/docs/current/datatype-json.html#DATATYPE-JSONPATH
Nota
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
On 2022-06-30 Th 04:19, Amit Kapila wrote:
> On Wed, Jun 29, 2022 at 6:58 PM Erik Rijkers wrote:
>> Op 29-06-2022 om 15:00 schreef Amit Kapila:
>>> On Mon, Jun 27, 2022 at 8:46 PM Andrew Dunstan wrote:
>>>> On 2022-06-26 Su 11:44, Erik Rijkers
On Wed, Jun 29, 2022 at 6:58 PM Erik Rijkers wrote:
>
> Op 29-06-2022 om 15:00 schreef Amit Kapila:
> > On Mon, Jun 27, 2022 at 8:46 PM Andrew Dunstan wrote:
> >>
> >> On 2022-06-26 Su 11:44, Erik Rijkers wrote:
> >>> JSON/SQL jsonpath
> >>>
On 2022-06-29 We 10:58, Alexander Korotkov wrote:
> On Wed, Jun 29, 2022 at 4:28 PM Erik Rijkers wrote:
>> Op 29-06-2022 om 15:00 schreef Amit Kapila:
>>> On Mon, Jun 27, 2022 at 8:46 PM Andrew Dunstan wrote:
>>>> On 2022-06-26 Su 11:44, Erik Rijkers
On Wed, Jun 29, 2022 at 4:28 PM Erik Rijkers wrote:
> Op 29-06-2022 om 15:00 schreef Amit Kapila:
> > On Mon, Jun 27, 2022 at 8:46 PM Andrew Dunstan wrote:
> >>
> >> On 2022-06-26 Su 11:44, Erik Rijkers wrote:
> >>> JSON/SQL jsonpath
> >>>
&
Op 29-06-2022 om 15:00 schreef Amit Kapila:
On Mon, Jun 27, 2022 at 8:46 PM Andrew Dunstan wrote:
On 2022-06-26 Su 11:44, Erik Rijkers wrote:
JSON/SQL jsonpath
For example, a jsonpath string with deliberate typo 'like_regexp'
(instead of 'like_regex'):
select js
from (values (jsonb
On Mon, Jun 27, 2022 at 8:46 PM Andrew Dunstan wrote:
>
> On 2022-06-26 Su 11:44, Erik Rijkers wrote:
> > JSON/SQL jsonpath
> >
> > For example, a jsonpath string with deliberate typo 'like_regexp'
> > (instead of 'like_regex'):
> >
> > select js
> &g
On 2022-06-26 Su 11:44, Erik Rijkers wrote:
> JSON/SQL jsonpath
>
> For example, a jsonpath string with deliberate typo 'like_regexp'
> (instead of 'like_regex'):
>
> select js
> from (values (jsonb '{}')) as f(js)
> where js @? '$ ? (@ like_regexp "^xxx")';
&g
JSON/SQL jsonpath
For example, a jsonpath string with deliberate typo 'like_regexp'
(instead of 'like_regex'):
select js
from (values (jsonb '{}')) as f(js)
where js @? '$ ? (@ like_regexp "^xxx")';
ERROR: syntax error, unexpected IDENT_P at or near " " of jsonpath inp
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
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 :(
the object subscription syntax, as
in '$["keyA","keyB"]', should not require 'pg ' prefix, as it is a part
of the original JSONPath (https://goessner.net/articles/JsonPath/) and
is supported in multiple other implementations.
6. Object subscription syntax. This gives u
ral 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 them.
A brief description of the patches:
1. Introduced new jsonpath modifier 'pg' whi
10:58, Nikita Glukhov wrote:
> >
> > Hi, hackers!
> >
> > 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 S
> 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 them.
>
> A brief description of the pa
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
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
** are affected. So, it might happen that
> we force users to use strict-mode or chain call even if it's not
> necessary. I'm tending to just fix the doc and wait if there are mode
> complaints :)
The patch, which clarifies this situation in the docs is attached.
I'm going to push it if no objections.
--
Regards,
Alexander Korotkov
jsonpath-double-star-lax-docs.patch
Description: Binary data
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
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
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
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
> count
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
Hi!
We have a bug report which says that jsonpath ** operator behaves strangely
in the lax mode [1].
Naturally, the result of this query looks counter-intuitive.
# select jsonb_path_query_array('[{"a": 1, "b": [{"a": 2}]}]', 'lax
$.**.a');
jsonb_path_query_array
-
On Fri, Sep 25, 2020 at 2:02 AM Alexander Korotkov wrote:
> Other opinions?
Given no other opinions yet, I've pushed the both patches.
--
Regards,
Alexander Korotkov
On Sun, Sep 20, 2020 at 2:23 AM Nikita Glukhov wrote:
> The beta-tester of PG13 reported a inconsistency in our current jsonpath
> datetime() method implementation. By the standard format strings in
> datetime()
> allows only characters "-./,':; " to be used as separa
Hi!
The beta-tester of PG13 reported a inconsistency in our current jsonpath
datetime() method implementation. By the standard format strings in datetime()
allows only characters "-./,':; " to be used as separators in format strings.
But our to_json[b]() serializes timestamps into
Hi
I try to solve issue
https://stackoverflow.com/questions/63864906/plpgsql-parse-json-in-parameter-and-compose-json-out-parameter
with JSONPath and I have a problem to get index of some value in array. Is
it possible with JSONPath?
Regards
Pavel
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
c value, we
> > restrict that this numeric value should fit to double precision type.
> > If it doesn't fit, the current error message just says the following.
>
> > ERROR: jsonpath item method .double() can only be applied to a numeric value
>
> > But that's confusing, because
ecision type.
> If it doesn't fit, the current error message just says the following.
> ERROR: jsonpath item method .double() can only be applied to a numeric value
> But that's confusing, because .double() method is naturally applied to
> a numeric value. Patch makes this message explicitly rep
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
alue should fit to double precision type.
> If it doesn't fit, the current error message just says the following.
>
> ERROR: jsonpath item method .double() can only be applied to a numeric value
>
> But that's confusing, because .double() method is naturally applied to
> a numeric
the same way as
> > > CAST to double. However, standard references the standard behavior of
> > > CAST here, not behavior of your implementation of CAST. So, if we
> > > extend the functionality of standard CAST in our implementation, that
> > > doesn't automati
I concur with your point that just because PG does X in
> some other cases doesn't mean that we must do X in json or jsonpath.
>
> regards, tom lane
>
> [1] https://tools.ietf.org/html/rfc7159#page-6
>
>This specification allows implementations to set li
the standard behavior of
> > CAST here, not behavior of your implementation of CAST. So, if we
> > extend the functionality of standard CAST in our implementation, that
> > doesn't automatically mean we should extend the .double() jsonpath
> > method in the same way. Is it corre
of CAST. So, if we
> extend the functionality of standard CAST in our implementation, that
> doesn't automatically mean we should extend the .double() jsonpath
> method in the same way. Is it correct?
Right. We could, if we chose, extend jsonpath to allow Inf/NaN, but
I don't believ
not behavior of your implementation of CAST.
Typo here: please read "our implementation of CAST" here.
> So, if we
> extend the functionality of standard CAST in our implementation, that
> doesn't automatically mean we should extend the .double() jsonpath
> meth
esn't fit
in an IEEE double isn't portable [1]. So we're already very far above and
beyond the spec's requirements by using numeric. We don't need to improve
on that. But I concur with your point that just because PG does X in
some other cases doesn't mean that we must do X in json or jsonpa
tomatically mean we should extend the .double() jsonpath
method in the same way. Is it correct?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
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
standard.
The way I read it is that it requires the set of values that are legal
according to the standard to be processed the same way as CAST would.
While we certainly *could* choose to extend jsonpath, and/or jsonb
itself, to allow NaN/Inf, I do not think that it's sane to argue that
the
t;. Nor does the JSON standard provide any
> support for that position. So I think it is fine to leave NaN/Inf
> out of the world of what you can write in jsonpath.
>
rfc and sql json forbid Nan and Inf ( Technical Report is freely available,
https://standards.iso.org/ittf/PubliclyAva
castable into numbers. But NaN and Inf are not legal
numbers according to SQL, so there is nothing in that text that
justifies accepting "NaN". Nor does the JSON standard provide any
support for that position. So I think it is fine to leave NaN/Inf
out of the world of what you can write
fore their definition is only envisioning that a string representing
> a normal finite number should be castable to DOUBLE PRECISION. Thus,
> both of the relevant standards think that "numbers" are just finite
> numbers.
>
> So when neither JSON nor SQL consider that "
"numbers" are just finite
numbers.
So when neither JSON nor SQL consider that "NaN" is an allowed sort
of number, why are you doing violence to the code to allow it in a
jsonpath? And if you insist on doing such violence, why didn't you
do some more and kluge it to the po
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" */
> +
his. The adjacent test case showing
that 'inf' isn't accepted:
+select jsonb_path_query('"inf"', '$.double()');
+ERROR: non-numeric SQL/JSON item
+DETAIL: jsonpath item method .double() can only be applied to a numeric value
seems like a saner approach.
In short, I t
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
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
Hi, hackers!
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 them.
A brief description of the patches
m going to push these two patches if no objections.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
0001-Refactor-timestamp2timestamptz_opt_error-3.patch
Description: Binary data
0002-Refactor-jsonpath-s-compareDatetime-3.patch
Description: Binary data
On Sun, Oct 13, 2019 at 5:24 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > This patch also changes the way timestamp to timestamptz cast works.
> > Previously it did timestamp2tm() then tm2timestamp(). Instead, after
> > timestamp2tm() it calculates timezone offset and applies it to
> >
Alexander Korotkov writes:
> This patch also changes the way timestamp to timestamptz cast works.
> Previously it did timestamp2tm() then tm2timestamp(). Instead, after
> timestamp2tm() it calculates timezone offset and applies it to
> original timestamp value. I hope this is correct.
I'd
ing overflow handling easier, this refactoring saves some CPU
cycles.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
0002-Refactor-jsonpath-s-compareDatetime-2.patch
Description: Binary data
On Tue, Oct 1, 2019 at 1:41 PM Alexander Korotkov
wrote:
> So, basically standard requires us to suppress any error happening in
> filter expression.
Sounds like the standard is dumb, then. :-)
> But as I wrote before suppression of errors in
> datetime comparison may lead to surprising
Attached v2 patch rebased onto current master.
On 18.09.2019 18:10, Nikita Glukhov wrote:
Unfortunately, jsonpath lexer, in contrast to jsonpath parser, was written by
Teodor and me without a proper attention to the stanard. JSON path lexics is
is borrowed from the external ECMAScript [1
On Mon, Sep 30, 2019 at 10:56 PM Robert Haas wrote:
> On Sun, Sep 29, 2019 at 10:30 AM Alexander Korotkov
> wrote:
> > So, jsonpath behaves like 100 is not greater than 2020. This
> > looks like plain false. And user can't expect that unless she is
> > familiar wi
On Sun, Sep 29, 2019 at 10:30 AM Alexander Korotkov
wrote:
> So, jsonpath behaves like 100 is not greater than 2020. This
> looks like plain false. And user can't expect that unless she is
> familiar with our particular issues. Now I got opinion that such
> errors shouldn't b
it seems weird that some unsupported datatype combinations
> > cause hard errors while others do not. Maybe that's fine, but if so,
> > the function header comment is falling down on the job by not explaining
> > the reasoning.
>
> All cast errors are caught by jsonp
On 25.09.2019 22:55, Alexander Korotkov wrote:
On Mon, Sep 23, 2019 at 10:05 PM Alexander Korotkov
wrote:
I've reordered the patchset. I moved the most debatable patch, which
introduces and RR and changes parsing of YYY, YY and Y to the
end. I think we have enough of time in this
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
&
On Mon, Sep 23, 2019 at 10:05 PM Alexander Korotkov
wrote:
> I've reordered the patchset. I moved the most debatable patch, which
> introduces and RR and changes parsing of YYY, YY and Y to the
> end. I think we have enough of time in this release cycle to decide
> whether we want this.
>
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
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 ba
t free resource available, assuming standard itself isn't free.
> I am uncertain why JSONPath is considered part of the datatype any more so
> than string functions are considered part of the character datatype
> https://www.postgresql.org/docs/11/functions-string.html
Let me clarify
://standards.iso.org/ittf/PubliclyAvailableStandards/c067367_ISO_IEC_TR_19075-6_2017.zip
I am uncertain why JSONPath is considered part of the datatype any more so
than string functions are considered part of the character datatype
https://www.postgresql.org/docs/11/functions-string.html
On Mon, Sep 23, 2019
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 w
1 - 100 of 324 matches
Mail list logo
