Re: [HACKERS] SQL/JSON in PostgreSQL

2017-11-03 Thread Michael Paquier
On Fri, Nov 3, 2017 at 12:07 PM, Michael Paquier wrote: > The patch sent previously does not directly apply on HEAD, and as far > as I can see the last patch set published on > https://www.postgresql.org/message-id/2361ae4a-66b1-c6c5-ea6a-84851a1c0...@postgrespro.ru >

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-11-03 Thread Michael Paquier
On Fri, Nov 3, 2017 at 11:29 AM, Nikita Glukhov wrote: > By standard only string literals can be used in JSON path specifications. > But of course it is possible to allow to use variable jsonpath expressions > in > SQL/JSON functions. > > Attached patch implements this

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-11-03 Thread Nikita Glukhov
On 03.11.2017 00:32, Piotr Stefaniak wrote: On 2017-02-28 20:08, Oleg Bartunov wrote: The standard describes SQL/JSON path language, which used by SQL/JSON query operators to query JSON. It defines path language as string literal. We implemented the path language as JSONPATH data type, since

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-11-02 Thread Piotr Stefaniak
On 2017-02-28 20:08, Oleg Bartunov wrote: > Attached patch is an implementation of SQL/JSON data model from SQL-2016 > standard (ISO/IEC 9075-2:2016(E)) I've faintly started looking into this. > We created repository for reviewing (ask for write access) - >

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-11-02 Thread Pavel Stehule
Hi 2017-11-02 3:39 GMT+01:00 Peter Eisentraut : > Could someone clarify the status of this patch set? It has been in > "Waiting" mode since the previous CF and no new patch, just a few > questions from the author. > There was a state "needs review". I looked

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-11-01 Thread Peter Eisentraut
Could someone clarify the status of this patch set? It has been in "Waiting" mode since the previous CF and no new patch, just a few questions from the author. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services --

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-10-30 Thread Nikita Glukhov
Hi, hackers! I have a question about transformation of JSON constructors into executor nodes. In first letter in this thread we wrote: JSON_OBJECT(), JSON_ARRAY() constructors and IS JSON predicate are transformed into raw function calls. Here is an example explaining what it means: =#

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-10-01 Thread Pavel Stehule
2017-09-30 1:06 GMT+02:00 Nikita Glukhov : > On 29.09.2017 20:07, Pavel Stehule wrote: > > 2017-09-29 12:15 GMT+02:00 Pavel Stehule : > >> >> 2017-09-29 12:09 GMT+02:00 Nikita Glukhov : >> >>> >>> >>> I have some free time

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-29 Thread Pavel Stehule
2017-09-30 1:06 GMT+02:00 Nikita Glukhov : > On 29.09.2017 20:07, Pavel Stehule wrote: > > 2017-09-29 12:15 GMT+02:00 Pavel Stehule : > >> >> 2017-09-29 12:09 GMT+02:00 Nikita Glukhov : >> >>> >>> >>> I have some free time

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-29 Thread Pavel Stehule
2017-09-29 12:15 GMT+02:00 Pavel Stehule : > > > 2017-09-29 12:09 GMT+02:00 Nikita Glukhov : > >> >> >> I have some free time now. Is it last version? >> >> Regards >> >> Pavel >> >> Yes, this is still the latest version. Now I am working only on

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-29 Thread Pavel Stehule
2017-09-29 12:09 GMT+02:00 Nikita Glukhov : > > > I have some free time now. Is it last version? > > Regards > > Pavel > > Yes, this is still the latest version. Now I am working only on unfinished > WIP > patch no. 9, but I think it should be reviewed the last. > > ok

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-29 Thread Nikita Glukhov
On 29.09.2017 12:59, Pavel Stehule wrote: Hi 2017-09-16 1:31 GMT+02:00 Nikita Glukhov >: On 15.09.2017 22:36, Oleg Bartunov wrote: On Fri, Sep 15, 2017 at 7:31 PM, Robert Haas

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-29 Thread Pavel Stehule
Hi 2017-09-16 1:31 GMT+02:00 Nikita Glukhov : > On 15.09.2017 22:36, Oleg Bartunov wrote: > > On Fri, Sep 15, 2017 at 7:31 PM, Robert Haas >> wrote: >> >>> On Fri, Sep 15, 2017 at 10:10 AM, Daniel Gustafsson >>> wrote: >>>

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-18 Thread Nikita Glukhov
On 18.09.2017 00:38, Alvaro Herrera wrote: Nikita Glukhov wrote: 0007-json_table-v02.patch: - JSON_TABLE using XMLTABLE infrastructure 0008-json_table-json-v02.patch: - JSON_TABLE support for json type I'm confused ... why are these two patches and not a single one? As I sad before,

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-18 Thread Alvaro Herrera
Nikita Glukhov wrote: > 0007-json_table-v02.patch: > - JSON_TABLE using XMLTABLE infrastructure > > 0008-json_table-json-v02.patch: > - JSON_TABLE support for json type I'm confused ... why are these two patches and not a single one? -- Álvaro Herrera

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-17 Thread Alexander Korotkov
On Sun, Sep 17, 2017 at 11:08 AM, Oleg Bartunov wrote: > On 16 Sep 2017 02:32, "Nikita Glukhov" wrote: > > On 15.09.2017 22:36, Oleg Bartunov wrote: > > On Fri, Sep 15, 2017 at 7:31 PM, Robert Haas >> wrote: >> >>> On Fri,

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-17 Thread Oleg Bartunov
On 16 Sep 2017 02:32, "Nikita Glukhov" wrote: On 15.09.2017 22:36, Oleg Bartunov wrote: On Fri, Sep 15, 2017 at 7:31 PM, Robert Haas wrote: > >> On Fri, Sep 15, 2017 at 10:10 AM, Daniel Gustafsson >> wrote: >> >>> Can we expect

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-15 Thread Oleg Bartunov
On Fri, Sep 15, 2017 at 7:31 PM, Robert Haas wrote: > On Fri, Sep 15, 2017 at 10:10 AM, Daniel Gustafsson wrote: >> Can we expect a rebased version of this patch for this commitfest? Since >> it’s >> a rather large feature it would be good to get it in

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-15 Thread Robert Haas
On Fri, Sep 15, 2017 at 10:10 AM, Daniel Gustafsson wrote: > Can we expect a rebased version of this patch for this commitfest? Since it’s > a rather large feature it would be good to get it in as early as we can in the > process. Again, given that this needs a "major" rebase

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-15 Thread Daniel Gustafsson
> On 15 Aug 2017, at 04:30, Peter Eisentraut > wrote: > > On 3/15/17 11:56, David Steele wrote: >>> This patch has been moved to CF 2017-07. >> >> I did not manage to move this patch when I said had. It is now moved. > > Unsurprisingly, this patch needs a

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-08-14 Thread Peter Eisentraut
On 3/15/17 11:56, David Steele wrote: >> This patch has been moved to CF 2017-07. > > I did not manage to move this patch when I said had. It is now moved. Unsurprisingly, this patch needs a major rebase. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development,

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-15 Thread David Steele
On 3/7/17 11:05 PM, David Steele wrote: > On 3/7/17 11:38 AM, Andres Freund wrote: > > <...> > >>> We have a plenty of time and we dedicate one full-time developer for >>> this project. >> >> How about having that, and perhaps others, developer participate in >> reviewing patches and getting to

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-13 Thread Sven R. Kunze
On 13.03.2017 07:24, Nico Williams wrote: On Thu, Mar 09, 2017 at 07:12:07PM +0100, Sven R. Kunze wrote: From my day-to-day work I can tell, the date(time) type is the only missing piece of JSON to make it perfect for business applications (besides, maybe, a "currency" type). And a binary

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-13 Thread Sven R. Kunze
On 10.03.2017 20:28, Josh Berkus wrote: On 03/09/2017 10:12 AM, Sven R. Kunze wrote: SaltStack uses YAML for their tools, too. I personally can empathize with them (as a user of configuration management) about this as writing JSON would be nightmare with all the quoting, commas, curly braces

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-13 Thread Oleg Bartunov
On Mon, Mar 13, 2017 at 9:24 AM, Nico Williams wrote: > On Thu, Mar 09, 2017 at 07:12:07PM +0100, Sven R. Kunze wrote: > > From my day-to-day work I can tell, the date(time) type is the only > missing > > piece of JSON to make it perfect for business applications (besides,

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-13 Thread Pavel Stehule
2017-03-13 7:24 GMT+01:00 Nico Williams : > On Thu, Mar 09, 2017 at 07:12:07PM +0100, Sven R. Kunze wrote: > > From my day-to-day work I can tell, the date(time) type is the only > missing > > piece of JSON to make it perfect for business applications (besides, > maybe, > >

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-13 Thread Nico Williams
On Thu, Mar 09, 2017 at 07:12:07PM +0100, Sven R. Kunze wrote: > From my day-to-day work I can tell, the date(time) type is the only missing > piece of JSON to make it perfect for business applications (besides, maybe, > a "currency" type). And a binary type. And a chunked-string type (to avoid

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-13 Thread Nico Williams
On Thu, Mar 09, 2017 at 12:58:55PM -0500, Robert Haas wrote: > On Thu, Mar 9, 2017 at 12:48 PM, Sven R. Kunze wrote: > > On 08.03.2017 20:48, Peter van Hardenberg wrote: > >> > >> Small point of order: YAML is not strictly a super-set of JSON. > > > > I haven't read the whole

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-13 Thread Nico Williams
On Tue, Mar 07, 2017 at 10:43:16PM +0100, Sven R. Kunze wrote: > about the datetime issue: as far as I know, JSON does not define a > serialization format for dates and timestamps. Use strings in ISO 8601 format, with or without fractional seconds, and maybe with 5-digit years. > On the other

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-11 Thread Oleg Bartunov
On Fri, Mar 10, 2017 at 7:07 AM, Petr Jelinek wrote: > On 09/03/17 19:50, Peter van Hardenberg wrote: > > Anecdotally, we just stored dates as strings and used a convention (key > > ends in "_at", I believe) to interpret them. The lack of support for > > dates in

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-10 Thread Josh Berkus
On 03/09/2017 10:12 AM, Sven R. Kunze wrote: > On 08.03.2017 20:52, Magnus Hagander wrote: >> On Wed, Mar 8, 2017 at 11:48 AM, Peter van Hardenberg > > wrote: >> >> Small point of order: YAML is not strictly a super-set of JSON. >> >> Editorializing

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-10 Thread Magnus Hagander
On Thu, Mar 9, 2017 at 1:12 PM, Sven R. Kunze wrote: > On 08.03.2017 20:52, Magnus Hagander wrote: > > On Wed, Mar 8, 2017 at 11:48 AM, Peter van Hardenberg wrote: > >> Small point of order: YAML is not strictly a super-set of JSON. >> >> Editorializing slightly, I

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-10 Thread Sven R. Kunze
On 10.03.2017 05:07, Petr Jelinek wrote: The original complain was about JSON_VALUE extracting date but I don't understand why there is problem with that, the SQL/JSON defines that behavior. The RETURNING clause there is more or less just shorthand for casting with some advanced options.

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-09 Thread Petr Jelinek
On 09/03/17 19:50, Peter van Hardenberg wrote: > Anecdotally, we just stored dates as strings and used a convention (key > ends in "_at", I believe) to interpret them. The lack of support for > dates in JSON is well-known, universally decried... and not a problem > the PostgreSQL community can

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-09 Thread Sven R. Kunze
On 09.03.2017 19:50, Peter van Hardenberg wrote: Anecdotally, we just stored dates as strings and used a convention (key ends in "_at", I believe) to interpret them. The lack of support for dates in JSON is well-known, universally decried... and not a problem the PostgreSQL community can fix.

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-09 Thread Peter van Hardenberg
Anecdotally, we just stored dates as strings and used a convention (key ends in "_at", I believe) to interpret them. The lack of support for dates in JSON is well-known, universally decried... and not a problem the PostgreSQL community can fix. On Thu, Mar 9, 2017 at 10:24 AM, Sven R. Kunze

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-09 Thread Sven R. Kunze
On 09.03.2017 18:58, Robert Haas wrote: Also, even if the superset thing were true on a theoretical plane, I'm not sure it would do us much good in practice. If we start using YAML-specific constructs, we won't have valid JSON any more. If we use only things that are legal in JSON, YAML's

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-09 Thread Sven R. Kunze
On 08.03.2017 20:52, Magnus Hagander wrote: On Wed, Mar 8, 2017 at 11:48 AM, Peter van Hardenberg > wrote: Small point of order: YAML is not strictly a super-set of JSON. Editorializing slightly, I have not seen much interest in the world for YAML

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-09 Thread Robert Haas
On Thu, Mar 9, 2017 at 12:48 PM, Sven R. Kunze wrote: > On 08.03.2017 20:48, Peter van Hardenberg wrote: >> >> Small point of order: YAML is not strictly a super-set of JSON. > > I haven't read the whole standard, but from what I can see the standard > considers JSON an official

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-09 Thread Sven R. Kunze
On 08.03.2017 20:48, Peter van Hardenberg wrote: Small point of order: YAML is not strictly a super-set of JSON. I haven't read the whole standard, but from what I can see the standard considers JSON an official subset of itself: http://www.yaml.org/spec/1.2/spec.html Regards, Sven --

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-08 Thread Robert Haas
On Tue, Mar 7, 2017 at 2:38 PM, Andres Freund wrote: > On 2017-03-07 12:21:59 +0300, Oleg Bartunov wrote: >> On 2017-03-03 15:49:38 -0500, David Steele wrote: >> > I propose we move this patch to the 2017-07 CF so further development >> > and review can be done without haste

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-08 Thread Magnus Hagander
On Wed, Mar 8, 2017 at 11:48 AM, Peter van Hardenberg wrote: > Small point of order: YAML is not strictly a super-set of JSON. > > Editorializing slightly, I have not seen much interest in the world for > YAML support though I'd be interested in evidence to the contrary. > > The

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-08 Thread Peter van Hardenberg
Small point of order: YAML is not strictly a super-set of JSON. Editorializing slightly, I have not seen much interest in the world for YAML support though I'd be interested in evidence to the contrary. On Tue, Mar 7, 2017 at 1:43 PM, Sven R. Kunze wrote: > Hi, > > about the

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-08 Thread Oleg Bartunov
On Wed, Mar 8, 2017 at 7:05 AM, David Steele wrote: > On 3/7/17 11:38 AM, Andres Freund wrote: > > <...> > > We have a plenty of time and we dedicate one full-time developer for >>> this project. >>> >> >> How about having that, and perhaps others, developer participate in

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-08 Thread Oleg Bartunov
On Wed, Mar 8, 2017 at 12:43 AM, Sven R. Kunze wrote: > Hi, > > about the datetime issue: as far as I know, JSON does not define a > serialization format for dates and timestamps. > > On the other hand, YAML (as a superset of JSON) already supports a > language-independent

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-07 Thread David Steele
On 3/7/17 11:38 AM, Andres Freund wrote: <...> We have a plenty of time and we dedicate one full-time developer for this project. How about having that, and perhaps others, developer participate in reviewing patches and getting to the bottom of the commitfest? Should we end up being done

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-07 Thread Sven R. Kunze
Hi, about the datetime issue: as far as I know, JSON does not define a serialization format for dates and timestamps. On the other hand, YAML (as a superset of JSON) already supports a language-independent date(time) serialization format (http://yaml.org/type/timestamp.html). I haven't

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-07 Thread Andres Freund
Hi, On 2017-03-07 12:21:59 +0300, Oleg Bartunov wrote: > On 2017-03-03 15:49:38 -0500, David Steele wrote: > > I propose we move this patch to the 2017-07 CF so further development > > and review can be done without haste and as the standard becomes more > > accessible. +1 > I wanted to have

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-07 Thread Oleg Bartunov
On Fri, Mar 3, 2017 at 11:49 PM, David Steele wrote: > Hi Oleg, > > On 2/28/17 2:55 PM, Pavel Stehule wrote: > > 2017-02-28 20:08 GMT+01:00 Oleg Bartunov > > > Attached patch is an implementation of SQL/JSON data model from > > SQL-2016

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-03 Thread Pavel Stehule
2017-03-03 21:49 GMT+01:00 David Steele : > Hi Oleg, > > On 2/28/17 2:55 PM, Pavel Stehule wrote: > > 2017-02-28 20:08 GMT+01:00 Oleg Bartunov > > > Attached patch is an implementation of SQL/JSON data model from > > SQL-2016 standard (ISO/IEC

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-03 Thread David Steele
Hi Oleg, On 2/28/17 2:55 PM, Pavel Stehule wrote: > 2017-02-28 20:08 GMT+01:00 Oleg Bartunov > Attached patch is an implementation of SQL/JSON data model from > SQL-2016 standard (ISO/IEC 9075-2:2016(E)), which was published > 2016-12-15 and is available only

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-03-01 Thread Pavel Stehule
> > > >1. > >Added explicit casts bytea=>jsonb and jsonb=>bytea (for jsonb=>bytea >output using RETURNING bytea FORMAT JSONB and corresponding bytea=>jsonb >input using FORMAT JSONB). > > This point has sense in Oracle, where JSON is blob. But it is little bit obscure in

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-02-28 Thread Pavel Stehule
> > >>> >> Good work - it will be pretty big patch. >> >> There is a intersection with implementation of XMLTABLE. I prepared a >> executor infrastructure. So it can little bit reduce size of this patch. >> > > we considered your XMLTABLE patch, but it's itself pretty big and in > unknown state.

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-02-28 Thread Oleg Bartunov
On Tue, Feb 28, 2017 at 10:55 PM, Pavel Stehule wrote: > Hi > > > 2017-02-28 20:08 GMT+01:00 Oleg Bartunov : > >> Hi there, >> >> >> Attached patch is an implementation of SQL/JSON data model from SQL-2016 >> standard (ISO/IEC 9075-2:2016(E)), which

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-02-28 Thread Pavel Stehule
Hi 2017-02-28 20:08 GMT+01:00 Oleg Bartunov : > Hi there, > > > Attached patch is an implementation of SQL/JSON data model from SQL-2016 > standard (ISO/IEC 9075-2:2016(E)), which was published 2016-12-15 and is > available only for purchase from ISO web site ( >