On Tue, Feb 27, 2024 at 12:40 PM Andrew Dunstan wrote:
>
> On 2024-02-02 Fr 00:31, Jeevan Chalke wrote:
>
>
>
> On Thu, Feb 1, 2024 at 11:25 AM Kyotaro Horiguchi
> wrote:
>
>> At Thu, 1 Feb 2024 09:22:22 +0530, Jeevan Chalke <
>> jeevan.cha...@enterprisedb.com> wrote in
>> > On Thu, Feb 1, 2024
On 2024-02-02 Fr 00:31, Jeevan Chalke wrote:
On Thu, Feb 1, 2024 at 11:25 AM Kyotaro Horiguchi
wrote:
At Thu, 1 Feb 2024 09:22:22 +0530, Jeevan Chalke
wrote in
> On Thu, Feb 1, 2024 at 7:24 AM Kyotaro Horiguchi
> wrote:
>
> > At Thu, 01 Feb 2024 10:49:57
On Thu, Feb 1, 2024 at 11:25 AM Kyotaro Horiguchi
wrote:
> At Thu, 1 Feb 2024 09:22:22 +0530, Jeevan Chalke <
> jeevan.cha...@enterprisedb.com> wrote in
> > On Thu, Feb 1, 2024 at 7:24 AM Kyotaro Horiguchi <
> horikyota@gmail.com>
> > wrote:
> >
> > > At Thu, 01 Feb 2024 10:49:57 +0900
Sorry for a minor correction, but..
At Thu, 01 Feb 2024 14:53:57 +0900 (JST), Kyotaro Horiguchi
wrote in
> Ah.. Understood. "NaN or Infinity" cannot be used in those
> cases. Additionally, for jpiBoolean and jpiBigint, we lack the text
> representation of the value.
This "Additionally" was
At Thu, 1 Feb 2024 09:22:22 +0530, Jeevan Chalke
wrote in
> On Thu, Feb 1, 2024 at 7:24 AM Kyotaro Horiguchi
> wrote:
>
> > At Thu, 01 Feb 2024 10:49:57 +0900 (JST), Kyotaro Horiguchi <
> > horikyota@gmail.com> wrote in
> > > By the way, while playing with this feature, I noticed the
At Thu, 1 Feb 2024 09:19:40 +0530, Jeevan Chalke
wrote in
> > As Tom suggested, given that similar situations have already been
> > disregarded elsewhere, worrying about excessively long input strings
> > in this specific instance won't notably improve safety in total.
> >
> > > Also, for
On Thu, Feb 1, 2024 at 7:24 AM Kyotaro Horiguchi
wrote:
> At Thu, 01 Feb 2024 10:49:57 +0900 (JST), Kyotaro Horiguchi <
> horikyota@gmail.com> wrote in
> > By the way, while playing with this feature, I noticed the following
> > error message:
> >
> > > select jsonb_path_query('1.1' ,
On Thu, Feb 1, 2024 at 7:20 AM Kyotaro Horiguchi
wrote:
> Thank you for the fix!
>
> At Tue, 30 Jan 2024 13:46:17 +0530, Jeevan Chalke <
> jeevan.cha...@enterprisedb.com> wrote in
> > On Mon, Jan 29, 2024 at 11:03 AM Tom Lane wrote:
> >
> > > Kyotaro Horiguchi writes:
> > > > Having said that,
At Thu, 01 Feb 2024 10:49:57 +0900 (JST), Kyotaro Horiguchi
wrote in
> By the way, while playing with this feature, I noticed the following
> error message:
>
> > select jsonb_path_query('1.1' , '$.boolean()');
> > ERROR: numeric argument of jsonpath item method .boolean() is out of range
>
Thank you for the fix!
At Tue, 30 Jan 2024 13:46:17 +0530, Jeevan Chalke
wrote in
> On Mon, Jan 29, 2024 at 11:03 AM Tom Lane wrote:
>
> > Kyotaro Horiguchi writes:
> > > Having said that, I'm a bit concerned about the case where an overly
> > > long string is given there. However,
On Mon, Jan 29, 2024 at 11:03 AM Tom Lane wrote:
> Kyotaro Horiguchi writes:
> > Having said that, I'm a bit concerned about the case where an overly
> > long string is given there. However, considering that we already have
> > "invalid input syntax for type xxx: %x" messages (including for the
Kyotaro Horiguchi writes:
> Having said that, I'm a bit concerned about the case where an overly
> long string is given there. However, considering that we already have
> "invalid input syntax for type xxx: %x" messages (including for the
> numeric), this concern might be unnecessary.
Yeah, we
At Sun, 28 Jan 2024 22:47:02 -0500, Tom Lane
wrote in
Kyotaro Horiguchi writes:
> They seem to be suggesting that PostgreSQL has the types
"decimal" and
> "number". I know of the former, but I don't think PostgreSQL has
the
> latter type. Perhaps the "number" was intended to refer to
Kyotaro Horiguchi writes:
> I have two possible issues in a recent commit.
> Commit 66ea94e8e6 has introduced the following messages:
>> errmsg("numeric argument of jsonpath item method .%s() is out of range for
>> type decimal or number",
> They seem to be suggesting that PostgreSQL has the
I have two possible issues in a recent commit.
Commit 66ea94e8e6 has introduced the following messages:
(Aplogizies in advance if the commit is not related to this thread.)
jsonpath_exec.c:1287
> if (numeric_is_nan(num) || numeric_is_inf(num))
> RETURN_ERROR(ereport(ERROR,
>
On Fri, Jan 26, 2024 at 2:57 AM Andrew Dunstan wrote:
>
> On 2024-01-25 Th 15:58, Tom Lane wrote:
> > I wrote:
> >> There's something else going on, because I'm still getting the
> >> assertion failure on my Mac with this fix in place. Annoyingly,
> >> it goes away if I compile with -O0, so
On 2024-01-25 Th 15:58, Tom Lane wrote:
I wrote:
There's something else going on, because I'm still getting the
assertion failure on my Mac with this fix in place. Annoyingly,
it goes away if I compile with -O0, so it's kind of hard to
identify what's going wrong.
No, belay that: I must've
On 2024-01-25 Th 15:33, Tom Lane wrote:
Andrew Dunstan writes:
On 2024-01-25 Th 14:31, Tom Lane wrote:
(The reported crashes seem to be happening later during a
recursive invocation, seemingly because JsonbType(jb) is
returning garbage. So there may be another bug after this one.)
I don't
I wrote:
> There's something else going on, because I'm still getting the
> assertion failure on my Mac with this fix in place. Annoyingly,
> it goes away if I compile with -O0, so it's kind of hard to
> identify what's going wrong.
No, belay that: I must've got confused about which version I
Andrew Dunstan writes:
> On 2024-01-25 Th 14:31, Tom Lane wrote:
>> (The reported crashes seem to be happening later during a
>> recursive invocation, seemingly because JsonbType(jb) is
>> returning garbage. So there may be another bug after this one.)
> I don't think so. AIUI The first call
On 2024-01-25 Th 14:31, Tom Lane wrote:
Andrew Dunstan writes:
Thanks, I have pushed this.
The buildfarm is pretty widely unhappy, mostly failing on
select jsonb_path_query('1.23', '$.string()');
On a guess, I tried running that under valgrind, and behold it said
==00:00:00:05.637
On 2024-01-25 Th 14:31, Tom Lane wrote:
Andrew Dunstan writes:
Thanks, I have pushed this.
The buildfarm is pretty widely unhappy, mostly failing on
select jsonb_path_query('1.23', '$.string()');
On a guess, I tried running that under valgrind, and behold it said
==00:00:00:05.637
Andrew Dunstan writes:
> Thanks, I have pushed this.
The buildfarm is pretty widely unhappy, mostly failing on
select jsonb_path_query('1.23', '$.string()');
On a guess, I tried running that under valgrind, and behold it said
==00:00:00:05.637 435530== Conditional jump or move depends on
On 2024-01-18 Th 09:25, Jeevan Chalke wrote:
On Thu, Jan 18, 2024 at 1:03 AM Peter Eisentraut
wrote:
On 17.01.24 10:03, Jeevan Chalke wrote:
> I added unary '+' and '-' support as well and thus thought of
having
> separate rules altogether rather than folding those in.
On 18.01.24 15:25, Jeevan Chalke wrote:
Peter, I didn't understand why the changes you did in your 0002 patch
were required here. I did run the pgindent, and it didn't complain to
me. So, just curious to know more about the changes. I have not merged
those changes in this single patch.
On 17.01.24 10:03, Jeevan Chalke wrote:
I added unary '+' and '-' support as well and thus thought of having
separate rules altogether rather than folding those in.
Per SQL standard, the precision and scale arguments are unsigned
integers, so unary plus and minus signs are not
On 2024-01-17 We 04:03, Jeevan Chalke wrote:
On Mon, Jan 15, 2024 at 7:41 PM Peter Eisentraut
wrote:
Overall, I think it would be better if you combined all three of
these
patches into one. Right now, you have arranged these as incremental
features, and as a result of
On Mon, Jan 15, 2024 at 7:41 PM Peter Eisentraut
wrote:
> Attached are two small fixup patches for your patch set.
>
Thanks, Peter.
>
> In the first one, I simplified the grammar for the .decimal() method.
> It seemed a bit overkill to build a whole list structure when all we
> need are 0, 1,
Attached are two small fixup patches for your patch set.
In the first one, I simplified the grammar for the .decimal() method.
It seemed a bit overkill to build a whole list structure when all we
need are 0, 1, or 2 arguments.
Per SQL standard, the precision and scale arguments are unsigned
On Thu, Jan 4, 2024 at 2:34 AM Peter Eisentraut
wrote:
> On 03.01.24 13:01, Peter Eisentraut wrote:
> > On 07.12.23 14:24, Jeevan Chalke wrote:
> >> We have the same issue with integer conversion and need a fix.
> >>
> >> Unfortunately, I was using int8in() for the conversion of numeric
> >>
On 03.01.24 13:01, Peter Eisentraut wrote:
On 07.12.23 14:24, Jeevan Chalke wrote:
We have the same issue with integer conversion and need a fix.
Unfortunately, I was using int8in() for the conversion of numeric
values. We should be using numeric_int8() instead. However, there is
no
On 07.12.23 14:24, Jeevan Chalke wrote:
We have the same issue with integer conversion and need a fix.
Unfortunately, I was using int8in() for the conversion of numeric
values. We should be using numeric_int8() instead. However, there is no
opt_error version of the same.
So, I have
On 2023-11-06 Mo 08:23, Jeevan Chalke wrote:
On Wed, Nov 1, 2023 at 3:49 PM Andrew Dunstan wrote:
On 2023-11-01 We 03:00, Jeevan Chalke wrote:
Hello,
On Tue, Oct 24, 2023 at 6:41 PM Andrew Dunstan
wrote:
On 2023-10-19 Th 02:06, Jeevan Chalke wrote:
On 2023-11-01 We 03:00, Jeevan Chalke wrote:
Hello,
On Tue, Oct 24, 2023 at 6:41 PM Andrew Dunstan
wrote:
On 2023-10-19 Th 02:06, Jeevan Chalke wrote:
Thanks, Peter for the comments.
On Fri, Oct 6, 2023 at 5:13 PM Peter Eisentraut
wrote:
On 29.08.23 09:05,
Hello,
On Tue, Oct 24, 2023 at 6:41 PM Andrew Dunstan wrote:
>
> On 2023-10-19 Th 02:06, Jeevan Chalke wrote:
>
> Thanks, Peter for the comments.
>
> On Fri, Oct 6, 2023 at 5:13 PM Peter Eisentraut
> wrote:
>
>> On 29.08.23 09:05, Jeevan Chalke wrote:
>> >
On 2023-10-19 Th 02:06, Jeevan Chalke wrote:
Thanks, Peter for the comments.
On Fri, Oct 6, 2023 at 5:13 PM Peter Eisentraut
wrote:
On 29.08.23 09:05, Jeevan Chalke wrote:
> v1-0001-Implement-jsonpath-.bigint-.integer-and-.number-m.patch
>
> This commit implements jsonpath
On Mon, Oct 23, 2023 at 3:29 PM Jeevan Chalke
wrote:
>
> Attached are all three patches fixing the above comments.
>
minor issue:
/src/backend/utils/adt/jsonpath_exec.c
2531: Timestamp result;
2532: ErrorSaveContext escontext = {T_ErrorSaveContext};
2533:
2534: /* Get a warning when precision is
On Wed, Oct 18, 2023 at 4:50 PM jian he wrote:
> On Fri, Oct 6, 2023 at 7:47 PM Peter Eisentraut
> wrote:
> >
> > On 29.08.23 09:05, Jeevan Chalke wrote:
> > > v1-0001-Implement-jsonpath-.bigint-.integer-and-.number-m.patch
> > >
> > > This commit implements jsonpath .bigint(), .integer(), and
Thanks, Peter for the comments.
On Fri, Oct 6, 2023 at 5:13 PM Peter Eisentraut
wrote:
> On 29.08.23 09:05, Jeevan Chalke wrote:
> > v1-0001-Implement-jsonpath-.bigint-.integer-and-.number-m.patch
> >
> > This commit implements jsonpath .bigint(), .integer(), and .number()
> > methods. The
On Fri, Oct 6, 2023 at 7:47 PM Peter Eisentraut wrote:
>
> On 29.08.23 09:05, Jeevan Chalke wrote:
> > v1-0001-Implement-jsonpath-.bigint-.integer-and-.number-m.patch
> >
> > This commit implements jsonpath .bigint(), .integer(), and .number()
> > methods. The JSON string or a numeric value is
On 29.08.23 09:05, Jeevan Chalke wrote:
v1-0001-Implement-jsonpath-.bigint-.integer-and-.number-m.patch
This commit implements jsonpath .bigint(), .integer(), and .number()
methods. The JSON string or a numeric value is converted to the
bigint, int4, and numeric type representation.
A
>
> Looking at the SQL standard itself, in the 2023 edition section 9.46
> "SQL/JSON path language: syntax and semantics", it shows this:
>
> ::=
> type
> | size
> | double
> | ceiling
> | floor
> | abs
> | datetime [ ]
> | keyvalue
> | bigint
> | boolean
> | date
> |
On 2023-08-31 20:50, Vik Fearing wrote:
— An SQL/JSON item is defined recursively as any of the following:
...
• An SQL/JSON array, defined as an ordered list of zero or more
SQL/JSON items, called the SQL/JSON elements of the SQL/JSON
array.
...
— An SQL/JSON sequence is an
On 8/30/23 19:20, Chapman Flack wrote:
On 2023-08-30 12:28, Alvaro Herrera wrote:
b) Otherwise, the result of JAE is the SQL/JSON sequence V_1,
..., V_n.
This has my Spidey sense tingling, as it seems very parallel to SQL/XML
where the result of XMLQUERY is to have type
On 2023-08-30 12:28, Alvaro Herrera wrote:
Yeah, I think the experience of the SQL committee with XML was pretty
bad, as you carefully documented. I hope they don't make such a mess
with JSON.
I guess the SQL committee was taken by surprise after basing something
on Infoset and XPath 1.0 for
On 2023-Aug-30, Chapman Flack wrote:
> Hi,
>
> On 2023-08-29 03:05, Jeevan Chalke wrote:
> > This commit implements jsonpath .bigint(), .integer(), and .number()
> > ---
> > This commit implements jsonpath .date(), .time(), .time_tz(),
> > .timestamp(), .timestamp_tz() methods.
> > ---
> > This
On 2023-08-30 11:18, Chapman Flack wrote:
If I look in [1], am I looking in the right place for the most
current jsonpath draft?
My bad, I see that it is not. Um if I look in [1'], am I then looking
at the same spec you are?
[1']
Hi,
On 2023-08-29 03:05, Jeevan Chalke wrote:
This commit implements jsonpath .bigint(), .integer(), and .number()
---
This commit implements jsonpath .date(), .time(), .time_tz(),
.timestamp(), .timestamp_tz() methods.
---
This commit implements jsonpath .boolean() and .string() methods.
48 matches
Mail list logo
