Re: SQL/JSON: functions

On 2022-07-07 Th 14:35, Andrew Dunstan wrote: > On 2022-07-07 Th 12:38, a.kozhemya...@postgrespro.ru wrote: >> Hello hackers, >> On branch REL_15_STABLE the following query: SELECT >> JSON_SERIALIZE('{"a":1}' RETURNING jsonb); >> >> produces SIGSEGV for me: You're not supposed to be able to

Re: SQL/JSON: functions

On 2022-07-07 Th 12:38, a.kozhemya...@postgrespro.ru wrote: > Hello hackers, > On branch REL_15_STABLE the following query: SELECT > JSON_SERIALIZE('{"a":1}' RETURNING jsonb); > > produces SIGSEGV for me: > #0  getJsonbOffset (index=39920251, jc=0x563cc5601d5c) at > jsonb_util.c:148 > 148

Re: SQL/JSON: functions

Hello hackers, On branch REL_15_STABLE the following query: SELECT JSON_SERIALIZE('{"a":1}' RETURNING jsonb); produces SIGSEGV for me: #0 getJsonbOffset (index=39920251, jc=0x563cc5601d5c) at jsonb_util.c:148 148 offset += JBE_OFFLENFLD(jc->children[i]); (gdb) bt #0 getJ

Re: SQL/JSON functions vs. ECPG vs. STRING as a reserved word

Noah Misch writes: > On Mon, May 30, 2022 at 05:20:15PM -0400, Tom Lane wrote: >> [allow EXEC SQL TYPE unreserved_keyword IS ...] > I didn't locate any problems beyond the test and doc gaps that you mentioned, > so I've marked this Ready for Committer. Thanks! Here's a fleshed-out version with

Re: SQL/JSON functions vs. ECPG vs. STRING as a reserved word

On Mon, May 30, 2022 at 05:20:15PM -0400, Tom Lane wrote: [allow EXEC SQL TYPE unreserved_keyword IS ...] > 1. In pgc.l, if an identifier is a typedef name, ignore any possible > keyword meaning and return it as an IDENT. (I'd originally supposed > that we'd want to return some new TYPEDEF token

Re: SQL/JSON functions vs. ECPG vs. STRING as a reserved word

On 2022-05-29 Su 16:19, Tom Lane wrote: > More generally, I feel like we have a process problem: there needs to > be a higher bar to adding new fully- or even partially-reserved words. > I might've missed it, but I don't recall that there was any discussion > of the compatibility implications of

Re: SQL/JSON functions vs. ECPG vs. STRING as a reserved word

Michael Meskes writes: >> This seems to be because what follows ecpgstart can be either a general >> SQL statement or an ECPGVarDeclaration (beginning with var_type), >> and bison isn't smart enough to disambiguate. I have a feeling that >> this situation could be improved with enough elbow greas

Re: SQL/JSON functions vs. ECPG vs. STRING as a reserved word

> I looked briefly at whether we could improve that situation. > Two of the four uses of ECPGColLabelCommon in ecpg.trailer can be > converted to the more general ECPGColLabel without difficulty, > but trying to change either of the uses in var_type results in > literally thousands of shift/reduce

Re: SQL/JSON: functions

Justin Pryzby writes: > On Mon, Apr 11, 2022 at 11:54:11AM -0400, Andrew Dunstan wrote: >> I will deal with the structural issues soon. > I didn't actually intend this as a complaint. The ability for a reference to > be specific and granular is good. So there may be reasons to change the > stru

Re: SQL/JSON: functions

On Mon, Apr 11, 2022 at 11:54:11AM -0400, Andrew Dunstan wrote: > >> BTW, the documentation references look a little like OIDs... > >> Does someone already have an SNMP-based doc browser ? > >> | For details, see Section 9.16.3.4.2. > > > > I already had a couple of these items on my list but I ran

Re: SQL/JSON: functions

On 2022-04-08 Fr 08:15, Andrew Dunstan wrote: > On 4/8/22 08:02, Justin Pryzby wrote: >> On Thu, Mar 31, 2022 at 04:25:58PM -0400, Andrew Dunstan wrote: >>> No code chunks left, only a documentation patch which should land >> Documentation review for a6baa4bad. >> >>> Construct a JSON the provide

Re: SQL/JSON: functions

On 4/8/22 08:02, Justin Pryzby wrote: > On Thu, Mar 31, 2022 at 04:25:58PM -0400, Andrew Dunstan wrote: >> No code chunks left, only a documentation patch which should land > Documentation review for a6baa4bad. > >> Construct a JSON the provided strings: > a JSON what ? > *from* the provided stri

Re: SQL/JSON: functions

On Thu, Mar 31, 2022 at 04:25:58PM -0400, Andrew Dunstan wrote: > No code chunks left, only a documentation patch which should land Documentation review for a6baa4bad. > Construct a JSON the provided strings: a JSON what ? *from* the provided strings ? > Construct a JSON from the provided value

Re: SQL/JSON: functions

On 3/31/22 15:54, Greg Stark wrote: > I see several commits referencing this entry. Can we mark it committed > or are there still chunks of commits to go? No code chunks left, only a documentation patch which should land tomorrow or Saturday. I am also planning on committing the JSON_TABLE p

Re: SQL/JSON: functions

I see several commits referencing this entry. Can we mark it committed or are there still chunks of commits to go?

Re: SQL/JSON: functions

Yes, it seems it was the ccache - I had enabled the 'ccache_failure_remove' flag last night and run a build, which failed, but the builds after that went green. Regards On Tue, 29 Mar 2022 at 06:41, Andres Freund wrote: > On 2022-03-28 19:25:51 -0400, Tom Lane wrote: > > ... even more baffling:

Re: SQL/JSON: functions

On 2022-03-28 19:25:51 -0400, Tom Lane wrote: > ... even more baffling: jabiru went green after the IS JSON patch. Broken ccache contents somehow?

Re: SQL/JSON: functions

> On Mar 28, 2022, at 7:25 PM, Tom Lane wrote: > > ... even more baffling: jabiru went green after the IS JSON patch. > > Yeah, bizarre. Let’s see if I can upset that tomorrow with the next patch :-) cheers andrew

Re: SQL/JSON: functions

... even more baffling: jabiru went green after the IS JSON patch. regards, tom lane

Re: SQL/JSON: functions

Andres Freund writes: > On 2022-03-28 14:57:20 -0400, Andrew Dunstan wrote: >> That didn't help, there are no differences that matter (just #line >> directives as I did a vpath build). :-( > Yea. I didn't see any differences when comparing to a non-vpath build that > runs tests successfully. Pret

Re: SQL/JSON: functions

Hi, On 2022-03-28 14:57:20 -0400, Andrew Dunstan wrote: > That didn't help, there are no differences that matter (just #line > directives as I did a vpath build). :-( Yea. I didn't see any differences when comparing to a non-vpath build that runs tests successfully. Pretty weird. Nikola, unless

Re: SQL/JSON: functions

On 3/28/22 14:31, Nikola Ivanov wrote: > Hi Andreas, > > Archive with the files is attached. That didn't help, there are no differences that matter (just #line directives as I did a vpath build). :-( cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

Re: SQL/JSON: functions

ok, I have enabled it. Will send it after the next build. Regards On Mon, 28 Mar 2022 at 18:39, Andres Freund wrote: > Hi, > > On 2022-03-28 18:05:19 +0300, Nikola Ivanov wrote: > > Let me know check what can I do with the access. I will get back to you > in > > an hour. > > Perhaps you can te

Re: SQL/JSON: functions

Hi Andrew, Let me know check what can I do with the access. I will get back to you in an hour. Regards On Mon, Mar 28, 2022, 17:30 Andrew Dunstan wrote: > > On 3/28/22 09:35, Tom Lane wrote: > > Andrew Dunstan writes: > >> On 3/27/22 19:14, Tom Lane wrote: > >>> What's worse, I'm unable to re

Re: SQL/JSON: functions

Hi, On 2022-03-28 18:05:19 +0300, Nikola Ivanov wrote: > Let me know check what can I do with the access. I will get back to you in > an hour. Perhaps you can temporarily enable keep_error_builds, and send in src/interfaces/ecpg/preproc/c_kwlist_d.h src/interfaces/ecpg/preproc/pgc.c src/interface

Re: SQL/JSON: functions

On 3/28/22 11:05, Nikola Ivanov wrote: > Hi Andrew, > > Let me know check what can I do with the access. I will get back to > you in an hour. Thanks for you help and prompt response. In the first instance we'd like to know what might be different about jabiru from the openbsd7/clang11 instance

Re: SQL/JSON: functions

On 3/28/22 09:35, Tom Lane wrote: > Andrew Dunstan writes: >> On 3/27/22 19:14, Tom Lane wrote: >>> What's worse, I'm unable to replicate the failure on an OpenBSD 7.0 >>> system here. So there's something odd about jabiru's build >>> environment; but what? >> It's hard to see how this could be

Re: SQL/JSON: functions

Andrew Dunstan writes: > On 3/27/22 19:14, Tom Lane wrote: >> What's worse, I'm unable to replicate the failure on an OpenBSD 7.0 >> system here. So there's something odd about jabiru's build >> environment; but what? > It's hard to see how this could be caused by the OS environment. Maybe a > f

Re: SQL/JSON: functions

On 3/27/22 19:14, Tom Lane wrote: > I wrote: >>> Andres Freund writes: There's also https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jabiru&dt=2022-03-22%2022%3A25%3A26 that started failing with ../../preproc/ecpg --regression -I./../../include -I. -o test1.c test1.pgc

Re: SQL/JSON: functions

On 3/27/22 20:50, Andres Freund wrote: > Hi, > > On 2022-03-27 20:21:05 -0400, Andrew Dunstan wrote: >> Very odd. How did it pick up just this commit and not the following one >> which was pushed at the same time? > The first recent failing run was with > f4fb45d15c Sun Mar 27 21:03:34 2022 UTC

Re: SQL/JSON: functions

Hi, On 2022-03-27 20:21:05 -0400, Andrew Dunstan wrote: > Very odd. How did it pick up just this commit and not the following one which > was pushed at the same time? The first recent failing run was with f4fb45d15c Sun Mar 27 21:03:34 2022 UTC SQL/JSON constructors f79b803dcc Sun Mar 27 21:03:

Re: SQL/JSON: functions

> On Mar 27, 2022, at 7:14 PM, Tom Lane wrote: > > I wrote: >>> Andres Freund writes: There's also https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jabiru&dt=2022-03-22%2022%3A25%3A26 that started failing with ../../preproc/ecpg --regression -I./../../include -I. -

Re: SQL/JSON: functions

I wrote: >> Andres Freund writes: >>> There's also >>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jabiru&dt=2022-03-22%2022%3A25%3A26 >>> that started failing with >>> ../../preproc/ecpg --regression -I./../../include -I. -o test1.c test1.pgc >>> test1.pgc:12: ERROR: syntax error at o

Re: SQL/JSON: functions

Hi, On 2022-03-24 18:51:30 -0400, Andrew Dunstan wrote: > I wonder if we should add these compile flags to the cfbot's setup? Yes, I think we should. There's a bit of discussion of that in and below https://postgr.es/m/20220213051937.GO31460%40telsasoft.com - that veered a bit of course, so I hav

Re: SQL/JSON: functions

On Wed, Mar 23, 2022 at 03:49:17PM -0400, Andrew Dunstan wrote: > > On 3/23/22 08:24, Justin Pryzby wrote: > > At least 0002-SQL-JSON-constructors-v64.patch has an issue with nodes, > > per COPY_PARSE_PLAN_TREES. > > > > +ERROR: unrecognized node type: 157 > > I just tried to reproduce this and

Re: SQL/JSON: functions

On 3/23/22 15:49, Andrew Dunstan wrote: > On 3/23/22 08:24, Justin Pryzby wrote: >> At least 0002-SQL-JSON-constructors-v64.patch has an issue with nodes, >> per COPY_PARSE_PLAN_TREES. >> >> +ERROR: unrecognized node type: 157 > > > I just tried to reproduce this and was unable to.  Ubuntu 20.04

Re: SQL/JSON: functions

On 3/23/22 08:24, Justin Pryzby wrote: > At least 0002-SQL-JSON-constructors-v64.patch has an issue with nodes, > per COPY_PARSE_PLAN_TREES. > > +ERROR: unrecognized node type: 157 I just tried to reproduce this and was unable to.  Ubuntu 20.04, gcc 9.4.0. the build was done with CPPFLAGS=-

Re: SQL/JSON: functions

At least 0002-SQL-JSON-constructors-v64.patch has an issue with nodes, per COPY_PARSE_PLAN_TREES. +ERROR: unrecognized node type: 157

Re: SQL/JSON: functions

I wrote: > Andres Freund writes: >> There's also >> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jabiru&dt=2022-03-22%2022%3A25%3A26 >> that started failing with >> ../../preproc/ecpg --regression -I./../../include -I. -o test1.c test1.pgc >> test1.pgc:12: ERROR: syntax error at or near

Re: SQL/JSON: functions

On 3/22/22 18:31, Tom Lane wrote: > I wrote: >> That patch is 0-for-three on my buildfarm animals. > ... the reason being that they use -Werror, and this patch spews > a bunch of warnings. This is not acceptable, especially not in > the middle of a CF when other people are trying to get work don

Re: SQL/JSON: functions

Andres Freund writes: > There's also > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jabiru&dt=2022-03-22%2022%3A25%3A26 > that started failing with > ../../preproc/ecpg --regression -I./../../include -I. -o test1.c test1.pgc > test1.pgc:12: ERROR: syntax error at or near "int" > with th

Re: SQL/JSON: functions

Hi, On 2022-03-22 18:31:39 -0400, Tom Lane wrote: > I wrote: > > That patch is 0-for-three on my buildfarm animals. > > ... the reason being that they use -Werror, and this patch spews > a bunch of warnings. This is not acceptable, especially not in > the middle of a CF when other people are try

Re: SQL/JSON: functions

I wrote: > That patch is 0-for-three on my buildfarm animals. ... the reason being that they use -Werror, and this patch spews a bunch of warnings. This is not acceptable, especially not in the middle of a CF when other people are trying to get work done. Please revert. r

Re: SQL/JSON: functions

Andrew Dunstan writes: > I have committed the first of these. That will break the cfbot for this > and the json_table patches. The remainder should be committed in the > following days. That patch is 0-for-three on my buildfarm animals. regards, tom lane

Re: SQL/JSON: functions

On 3/5/22 09:39, Andrew Dunstan wrote: > > here's a new set of patches, omitting the GUC patch and with the > beginnings of some message cleanup - there's more work to do there. > > > > This patchset restores the RETURNING clause for JSON() and JSON_SCALAR() > but without the GUC > > I have com

Re: SQL/JSON: functions

On 3/1/22 16:41, Andrew Dunstan wrote: > On 2/1/22 14:11,I wrote: >> 2. The new GUC "sql_json" is a bit of a worry. I understand what it's >> trying to do, but I'm trying to convince myself it's not going to be a >> fruitful source of error reports, especially if people switch it in the >> middle

Re: SQL/JSON: functions

On 2/1/22 14:11,I wrote: > > 2. The new GUC "sql_json" is a bit of a worry. I understand what it's > trying to do, but I'm trying to convince myself it's not going to be a > fruitful source of error reports, especially if people switch it in the > middle of a session. Maybe it should be an initdb

Re: SQL/JSON: functions

Hi, The last version conflicts with recent c4cc2850f4d1 (Rename value node fields). Can you send a rebased version?

Re: SQL/JSON: functions

On 12/9/21 09:04, Himanshu Upadhyaya wrote: > > > > Few comments For 0002-SQL-JSON-constructors-v59.patch: > 1) > +       if (IsA(node, JsonConstructorExpr)) > +       { > +               JsonConstructorExpr *ctor = (JsonConstructorExpr *) node; > +               ListCell   *lc; > +              

Re: SQL/JSON: functions

On 1/6/22 06:24, Himanshu Upadhyaya wrote: > I have one general question on the below scenario. > CREATE TABLE T (Id INTEGER PRIMARY KEY,Jcol CHARACTER VARYING ( 5000 > )CHECK ( Jcol IS JSON ) ); > insert into T values (1,323); > ORACLE is giving an error(check constraint...violated ORA-06512) f

Re: SQL/JSON: functions

On Tue, Jan 4, 2022 at 7:32 PM Andrew Dunstan wrote: I have one general question on the below scenario. CREATE TABLE T (Id INTEGER PRIMARY KEY,Jcol CHARACTER VARYING ( 5000 )CHECK ( Jcol IS JSON ) ); insert into T values (1,323); ORACLE is giving an error(check constraint...violated ORA-06512) f

Re: SQL/JSON: functions

On 1/5/22 00:51, Himanshu Upadhyaya wrote: > On Thu, Dec 9, 2021 at 7:34 PM Himanshu Upadhyaya > wrote: >> 3) >> Is not that result of the two below queries should match because both are >> trying to retrieve the information from the JSON object. >> >> postgres=# SELECT JSON_OBJECT('track' VALU

Re: SQL/JSON: functions

On Thu, Dec 9, 2021 at 7:34 PM Himanshu Upadhyaya wrote: > 3) > Is not that result of the two below queries should match because both are > trying to retrieve the information from the JSON object. > > postgres=# SELECT JSON_OBJECT('track' VALUE '{ > "segments": [ > { > "location

Re: SQL/JSON: functions

On 1/4/22 04:18, Himanshu Upadhyaya wrote: > On Thu, Dec 16, 2021 at 3:06 AM Andrew Dunstan wrote: >> >> >> SELECT JSON_OBJECTAGG(k: v ABSENT ON NULL) AS apt >> FROM (VALUES ('no', 5), ('area', 50), ('rooms', 2), ('foo', NULL), >> (5,5)) kv(k, v); >> ERROR: 22P02: invalid input syntax for type

Re: SQL/JSON: functions

út 4. 1. 2022 v 10:19 odesílatel Himanshu Upadhyaya < upadhyaya.himan...@gmail.com> napsal: > On Thu, Dec 16, 2021 at 3:06 AM Andrew Dunstan > wrote: > > > > > > On 12/9/21 09:04, Himanshu Upadhyaya wrote: > > > > > > > > > > > > 4) > > > Are we intentionally allowing numeric keys in JSON_OBJECT

Re: SQL/JSON: functions

On Thu, Dec 16, 2021 at 3:06 AM Andrew Dunstan wrote: > > > On 12/9/21 09:04, Himanshu Upadhyaya wrote: > > > > > > > > 4) > > Are we intentionally allowing numeric keys in JSON_OBJECT but somehow > > these are not allowed in ORACLE? > > ‘postgres[151876]=#’select JSON_OBJECT( 3+1:2, 2+2:1); > >

Re: SQL/JSON: functions

On 12/9/21 09:04, Himanshu Upadhyaya wrote: > > > > 2) > I am not sure if below is required as per SQL standard, ORACLE is > allowing to construct JSON_OBJECT bases on the records in the table as > below, but postgres parser is not allowing: > create table test (id varchar(10), value int); > inse

Re: SQL/JSON: functions

On 12/9/21 09:04, Himanshu Upadhyaya wrote: > > > > 4) > Are we intentionally allowing numeric keys in JSON_OBJECT but somehow > these are not allowed in ORACLE? > ‘postgres[151876]=#’select JSON_OBJECT( 3+1:2, 2+2:1); >     json_object > >  {"4" : 2, "4" : 1} > (1 row) > > I

Re: SQL/JSON: functions

On 09.12.21 15:04, Himanshu Upadhyaya wrote: 1) Why we don't support KEY(however is optional as per SQL standard) keyword? SELECT JSON_OBJECT(KEY 'a' VALUE '123'); ERROR:  type "key" does not exist LINE 1: SELECT JSON_OBJECT(KEY 'a' VALUE '123'); ORACLE is supporting the above syntax. I can see

Re: SQL/JSON: functions

On Thu, Sep 16, 2021 at 8:23 PM Andrew Dunstan wrote: > > On 9/14/21 8:55 AM, Andrew Dunstan wrote: > I have tried with few of the test cases of constructor function, wanted to check on the below scenarios: 1) Why we don't support KEY(however is optional as per SQL standard) keyword? SELECT JS

Re: SQL/JSON: functions

On Wed, Dec 1, 2021 at 7:56 PM Andrew Dunstan wrote: > > On 12/1/21 06:13, Himanshu Upadhyaya wrote: > > Hi Andrew, > > > > The latest version (v59) is not applying on head. > > Could you please help to rebase? > > > > > > (Please don't top-post on PostgreSQL lists) > > Sure, I will take care of

Re: SQL/JSON: functions

On 12/1/21 06:13, Himanshu Upadhyaya wrote: > Hi Andrew, > > The latest version (v59) is not applying on head. > Could you please help to rebase? > > (Please don't top-post on PostgreSQL lists) The patches apply for me and for the cfbot: . I'm not s

Re: SQL/JSON: functions

Hi Andrew, The latest version (v59) is not applying on head. Could you please help to rebase? Thanks, Himanshu On Thu, Sep 16, 2021 at 8:23 PM Andrew Dunstan wrote: > > On 9/14/21 8:55 AM, Andrew Dunstan wrote: > > On 9/2/21 2:50 PM, Andrew Dunstan wrote: > >> On 5/18/21 3:22 PM, Andrew Dunsta

Re: SQL/JSON: functions

On Sat, May 8, 2021 at 11:21 AM Andrew Dunstan wrote: > > On 4/28/21 5:55 PM, Andrew Dunstan wrote: > > > > > > On Fri, Mar 26, 2021 at 9:14 PM Nikita Glukhov > > mailto:n.glu...@postgrespro.ru>> wrote: > > > > Attached 54th version of the patches rebased onto current master. > > > > On 2

Re: SQL/JSON: functions

On Fri, Mar 26, 2021 at 9:14 PM Nikita Glukhov wrote: > Attached 54th version of the patches rebased onto current master. > > > On 27.03.2021 01:30, Andrew Dunstan wrote: > > Specifically, patch 4 (SQL-JSON-query-functions) fails with this when > built with LLVM: > > > There is also a bug that re

Re: SQL/JSON: functions

On 3/26/21 4:49 PM, Andrew Dunstan wrote: > On 3/26/21 4:22 PM, Andrew Dunstan wrote: >> On 3/8/21 1:55 PM, Ibrar Ahmed wrote: >>> On Sat, Jan 23, 2021 at 3:37 PM Erik Rijkers >> > wrote: >>> >>> On 2021-01-20 03:49, Nikita Glukhov wrote: >>> >>> > [0001-Add-common-

Re: SQL/JSON: functions

On 3/26/21 4:22 PM, Andrew Dunstan wrote: > On 3/8/21 1:55 PM, Ibrar Ahmed wrote: >> >> On Sat, Jan 23, 2021 at 3:37 PM Erik Rijkers > > wrote: >> >> On 2021-01-20 03:49, Nikita Glukhov wrote: >> >> > [0001-Add-common-SQL-JSON-clauses-v52.patch.gz] >> > [0002-SQ

Re: SQL/JSON: functions

On Sat, Jan 23, 2021 at 3:37 PM Erik Rijkers wrote: > On 2021-01-20 03:49, Nikita Glukhov wrote: > > > [0001-Add-common-SQL-JSON-clauses-v52.patch.gz] > > [0002-SQL-JSON-constructors-v52.patch.gz] > > [0003-IS-JSON-predicate-v52.patch.gz] > > [0004-SQL-JSON-query-functions-v52.patch.gz] > > [0005

Re: SQL/JSON: functions

On 2021-01-20 03:49, Nikita Glukhov wrote: [0001-Add-common-SQL-JSON-clauses-v52.patch.gz] [0002-SQL-JSON-constructors-v52.patch.gz] [0003-IS-JSON-predicate-v52.patch.gz] [0004-SQL-JSON-query-functions-v52.patch.gz] [0005-SQL-JSON-functions-for-json-type-v52.patch.gz] [0006-GUC-sql_json-v52.patc

Re: SQL/JSON: functions

Hi, For ExecEvalJsonExprSubtrans(), if you check !subtrans first, + /* No need to use subtransactions. */ + return func(op, econtext, res, resnull, p, error); The return statement would allow omitting the else keyword and left-indent the code in the current if block. For ExecEvalJson

Re: SQL/JSON: functions

For 0001-Common-SQL-JSON-clauses-v51.patch : + /* | implementation_defined_JSON_representation_option (BSON, AVRO etc) */ I don't find implementation_defined_JSON_representation_option in the patchset. Maybe rephrase the above as a comment without implementation_defined_JSON_representation

Re: SQL/JSON: functions

út 15. 12. 2020 v 19:56 odesílatel Oleg Bartunov napsal: > On Tue, Dec 15, 2020 at 8:37 PM Pavel Stehule > wrote: > > > > > > > > út 15. 12. 2020 v 18:00 odesílatel Simon Riggs > napsal: > >> > >> On Fri, 17 Jul 2020 at 21:26, Nikita Glukhov > wrote: > >> > > >> > Attached 50th version of the

Re: SQL/JSON: functions

On Tue, Dec 15, 2020 at 8:37 PM Pavel Stehule wrote: > > > > út 15. 12. 2020 v 18:00 odesílatel Simon Riggs napsal: >> >> On Fri, 17 Jul 2020 at 21:26, Nikita Glukhov wrote: >> > >> > Attached 50th version of the patches. Only the documentation was changed >> > since the previous version. >> >>

Re: SQL/JSON: functions

On Tue, Dec 15, 2020 at 8:01 PM Simon Riggs wrote: > > On Fri, 17 Jul 2020 at 21:26, Nikita Glukhov wrote: > > > > Attached 50th version of the patches. Only the documentation was changed > > since the previous version. > > I can imagine the effort required to get to v50, so I salute your efforts

Re: SQL/JSON: functions

út 15. 12. 2020 v 18:00 odesílatel Simon Riggs napsal: > On Fri, 17 Jul 2020 at 21:26, Nikita Glukhov > wrote: > > > > Attached 50th version of the patches. Only the documentation was changed > > since the previous version. > > I can imagine the effort required to get to v50, so I salute your ef

Re: SQL/JSON: functions

On Fri, 17 Jul 2020 at 21:26, Nikita Glukhov wrote: > > Attached 50th version of the patches. Only the documentation was changed > since the previous version. I can imagine the effort required to get to v50, so I salute your efforts. The document for SQL Standard has now been published as CD 907

Re: SQL/JSON: functions

On Sat, Jul 18, 2020 at 09:24:11AM -0400, Andrew Dunstan wrote: > I think patches 5 and 6 need to be submitted to the next commitfest, > This is far too much scope creep to be snuck in under the current CF item. > > I'll look at patches 1-4. Even with that, the patch set has been waiting on autho

Re: SQL/JSON: functions

On 7/17/20 4:26 PM, Nikita Glukhov wrote: > >>> Patch #5 implements functions for new JSON type that is expected to appear >>> in >>> the upcoming SQL/JSON standard: >>> >>> - JSON() is for constructing JSON typed values from JSON text. >>>It is almost equivalent to text::json[b] cast, exce

Re: SQL/JSON: functions

On 7/14/20 9:47 PM, Nikita Glukhov wrote: > Attached 49th version of the patches with two new patches #5 and #6. > > On 15.07.2020 00:09, Andrew Dunstan wrote: >> On 7/14/20 1:00 PM, Andrew Dunstan wrote: >>> On 7/5/20 1:29 PM, Justin Pryzby wrote: On Mon, Mar 23, 2020 at 08:28:52PM +0300, N

Re: SQL/JSON: functions

On 7/14/20 1:00 PM, Andrew Dunstan wrote: > On 7/5/20 1:29 PM, Justin Pryzby wrote: >> On Mon, Mar 23, 2020 at 08:28:52PM +0300, Nikita Glukhov wrote: >>> Attached 47th version of the patches. >> The patch checker/cfbot says this doesn't apply ; could you send a rebasified >> version ? >> > To ke

Re: SQL/JSON: functions

On Mon, Mar 23, 2020 at 08:28:52PM +0300, Nikita Glukhov wrote: > Attached 47th version of the patches. The patch checker/cfbot says this doesn't apply ; could you send a rebasified version ? -- Justin

Re: SQL/JSON: functions

On Mon, Mar 23, 2020 at 8:28 PM Nikita Glukhov wrote: > Attached 47th version of the patches. > > On 21.03.2020 22:38, Pavel Stehule wrote: > > > On 21. 3. 2020 v 11:07 Nikita Glukhov wrote: >> >> Attached 46th version of the patches. >> >> On 20.03.2020 22:34, Pavel Stehule wrote: >> >> >> On 19

Re: SQL/JSON: functions

Attached 47th version of the patches. On 21.03.2020 22:38, Pavel Stehule wrote: On 21. 3. 2020 v 11:07 Nikita Glukhov > wrote: Attached 46th version of the patches. On 20.03.2020 22:34, Pavel Stehule wrote: On 19.03.2020 23:57 Nikita Glukhov mail

Re: SQL/JSON: functions

so 21. 3. 2020 v 11:07 odesílatel Nikita Glukhov napsal: > Attached 46th version of the patches. > > > On 20.03.2020 22:34, Pavel Stehule wrote: > > > čt 19. 3. 2020 v 23:57 odesílatel Nikita Glukhov > napsal: > >> Attached 45th version of the patches. >> >> Nodes JsonFormat, JsonReturning, Json

Re: SQL/JSON: functions

Attached 46th version of the patches. On 20.03.2020 22:34, Pavel Stehule wrote: čt 19. 3. 2020 v 23:57 odesílatel Nikita Glukhov mailto:n.glu...@postgrespro.ru>> napsal: Attached 45th version of the patches. Nodes JsonFormat, JsonReturning, JsonPassing, JsonBehavior were fixed.

Re: SQL/JSON: functions

čt 19. 3. 2020 v 23:57 odesílatel Nikita Glukhov napsal: > Attached 45th version of the patches. > > Nodes JsonFormat, JsonReturning, JsonPassing, JsonBehavior were fixed. > > > On 17.03.2020 21:35, Pavel Stehule wrote: > > > út 17. 3. 2020 v 1:55 odesílatel Nikita Glukhov > napsal: > >> Attache

Re: SQL/JSON: functions

út 17. 3. 2020 v 1:55 odesílatel Nikita Glukhov napsal: > Attached 44th version of the patches. > > > On 12.03.2020 16:41, Pavel Stehule wrote: > > > On 12.03.2020 00:09 Nikita Glukhov wrote: > >> Attached 43rd version of the patches. >> >> The previous patch #4 ("Add function formats") was remov

Re: SQL/JSON: functions

čt 12. 3. 2020 v 0:09 odesílatel Nikita Glukhov napsal: > Attached 43rd version of the patches. > > The previous patch #4 ("Add function formats") was removed. > Instead, introduced new executor node JsonCtorExpr which is used to wrap > SQL/JSON constructor function calls (FuncExpr, Aggref, Windo

Re: SQL/JSON: functions

út 3. 3. 2020 v 0:24 odesílatel Nikita Glukhov napsal: > On 03.03.2020 2:12, Erik Rijkers wrote: > > > On 2020-03-02 23:33, Nikita Glukhov wrote: > >> Attached 42th version of the patches. > > > >> v1-0001-Add-jsonpath-pg-modifier-for-enabling-extensions.patch > >> v1-0002-Add-raw-jbvArray-and-jb

Re: SQL/JSON: functions

On 2020-03-03 00:24, Nikita Glukhov wrote: On 03.03.2020 2:12, Erik Rijkers wrote: On 2020-03-02 23:33, Nikita Glukhov wrote: Attached 42th version of the patches. 20200302/0001-Jsonpath-support-for-json-v42.patch + 20200302/0002-Add-common-SQL_JSON-clauses-v42.patch+ 20200302/0003-Add-inv

Re: SQL/JSON: functions

On 2020-03-02 23:33, Nikita Glukhov wrote: Attached 42th version of the patches. v1-0001-Add-jsonpath-pg-modifier-for-enabling-extensions.patch v1-0002-Add-raw-jbvArray-and-jbvObject-support-to-jsonpat.patch v1-0003-Add-jsonpath-sequence-constructors.patch v1-0004-Add-jsonpath-array-constructo

Re: SQL/JSON: functions

so 18. 1. 2020 v 18:46 odesílatel Nikita Glukhov napsal: > Attached 41th version of the patches. > > Changes since previous version: > * Enabled DEFAULT clause for ON ERROR/ON EMPTY behaviors in JSON_QUERY() > * Added RETURNING clause to JSON_EXISTS() ("side effect" of implementation >EXIST

Re: SQL/JSON: functions

Hi čt 14. 11. 2019 v 17:46 odesílatel Nikita Glukhov napsal: > Attached 40th version of the patches. > > > I have added some documentation which has been simply copied from [1]. > > Also, I have split patches more correctly, and extracted patch #2 with common > SQL/JSON clauses, that are used by

Re: Re: SQL/JSON: functions

On 10/21/19 12:44 PM, Nikita Glukhov wrote: v39 patch is based on 5ee96b3e2221d154ffcb719bd2dee1179c53f821 Use the following git command to apply patches: git am ~/Downloads/0001-Jsonpath-support-for-json-v39.patch Thank you. The patch applied fine, with no errors. Is this the type of test

Re: SQL/JSON: functions

On 21.10.2019 19:00, Andrew Alsup wrote: On 9/27/19 9:42 PM, Nikita Glukhov wrote: Attached 39th version of the patches rebased onto current master. I am unable to cleanly apply this patch. I've tried applying to the current master (4f4061b2dd) I've also tried apply to commit b81a9c2fc5 back

Re: Re: SQL/JSON: functions

On 9/27/19 9:42 PM, Nikita Glukhov wrote: Attached 39th version of the patches rebased onto current master. -- Nikita Glukhov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company I am unable to cleanly apply this patch. I've tried applying to the current master (4f4061

Re: SQL/JSON: functions

This has recently been broken -- please rebase. (JSON_TABLE likewise). -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: SQL/JSON: functions

On 2019-Jul-16, Nikita Glukhov wrote: > Attached 37th version of the patches rebased onto current master. > > Preliminary patch #1 contains: >  - implementation of jsonpath .datetime() method (see [1]) >  - jsonpath support for json type (should be posted later in a separate > thread) 0001 doesn

Re: Re: SQL/JSON: functions

On Tue, May 14, 2019 at 12:54 PM Andrew Alsup wrote: > On 3/5/19 5:35 PM, Nikita Glukhov wrote: > > Attached 36th version of the patches rebased onto jsonpath v36. > While testing this patch a found a few issues: > > [1] I was not able to apply the patch to the current HEAD. However, it > applies

Re: Re: SQL/JSON: functions

Hi! On Tue, May 14, 2019 at 3:54 AM Andrew Alsup wrote: > array slicing [0:], [:1], and [0:1] do not work:$.c1.c2[0:].b3 > > # select json_path_query('{"a1": 123, "b1": "xxx", "c1": {"a2": 456, > "b2": "yyy", "c2": [{"a3": 777, "b3": "7z"},{"a3": 888, "b3": > "8z"}]}}'::json, '$.c1.c2[0:].b3'::js

  1   2   >