Re: [HACKERS] SQL procedures

On Wed, Nov 8, 2017 at 11:03 AM, Peter Eisentraut wrote: > On 11/8/17 11:11, Merlin Moncure wrote: >> On Wed, Nov 8, 2017 at 9:13 AM, Peter Eisentraut >> wrote: >>> I have already submitted a separate patch that addresses these questions. >> >> Maybe I'm obtuse, but I'm not seeing it? In very int

Re: [HACKERS] SQL procedures

On 11/8/17 11:11, Merlin Moncure wrote: > On Wed, Nov 8, 2017 at 9:13 AM, Peter Eisentraut > wrote: >> I have already submitted a separate patch that addresses these questions. > > Maybe I'm obtuse, but I'm not seeing it? In very interested in the > general approach to transaction management; if

Re: [HACKERS] SQL procedures

On Wed, Nov 8, 2017 at 9:13 AM, Peter Eisentraut wrote: > I have already submitted a separate patch that addresses these questions. Maybe I'm obtuse, but I'm not seeing it? In very interested in the general approach to transaction management; if you've described it in the patch I'll read it there

Re: [HACKERS] SQL procedures

On 11/8/17 09:23, Merlin Moncure wrote: > I do wonder how transaction control could be added later. > > The last time I (lightly) looked at this, I was starting to think that > working transaction control into the SPI interface was the wrong > approach; pl/pgsql would have to adopt a very differen

Re: [HACKERS] SQL procedures

On 11/8/17 09:33, Pavel Stehule wrote: > We can create auto session variable STATUS. This variable can be 0 > if procedure was returned without explicit RETURN value. Or it can > hold different value specified by RETURN expr. > > This value can be read by GET DIAGNOSTICS xxx = STAT

Re: [HACKERS] SQL procedures

On 11/6/17 16:27, Simon Riggs wrote: > You mention PARALLEL SAFE is not used for procedures. Isn't it an > architectural restriction that procedures would not be able to execute > in parallel? (At least this year) I'm not sure what you are referring to here. I don't think the functionality I'm pr

Re: [HACKERS] SQL procedures

Peter Eisentraut writes: > On 10/31/17 14:23, Tom Lane wrote: >> Why not use VOIDOID for the prorettype value? > We need a way to distinguish functions that are callable by SELECT and > procedures that are callable by CALL. Do procedures of this ilk belong in pg_proc at all? It seems like a lar

Re: [HACKERS] SQL procedures

On 08.11.2017 17:23, Merlin Moncure wrote: On Tue, Oct 31, 2017 at 12:23 PM, Peter Eisentraut wrote: - Transaction control in procedure bodies This feature is really key, since it enables via SQL lots of things that are not possible without external coding, including: *) very long running pr

Re: [HACKERS] SQL procedures

2017-11-08 15:31 GMT+01:00 Pavel Stehule : > > > 2017-11-08 15:23 GMT+01:00 Peter Eisentraut com>: > >> On 10/31/17 16:50, Pavel Stehule wrote: >> > Not sure if disabling RETURN is good idea. I can imagine so optional >> > returning something like int status can be good idea. Cheaper than >> > ra

Re: [HACKERS] SQL procedures

2017-11-08 15:23 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 10/31/17 16:50, Pavel Stehule wrote: > > Not sure if disabling RETURN is good idea. I can imagine so optional > > returning something like int status can be good idea. Cheaper than > > raising a exception. > > We

Re: [HACKERS] SQL procedures

On Tue, Oct 31, 2017 at 12:23 PM, Peter Eisentraut wrote: > - Transaction control in procedure bodies This feature is really key, since it enables via SQL lots of things that are not possible without external coding, including: *) very long running processes in a single routine *) transaction iso

Re: [HACKERS] SQL procedures

On 10/31/17 16:50, Pavel Stehule wrote: > Not sure if disabling RETURN is good idea. I can imagine so optional > returning something like int status can be good idea. Cheaper than > raising a exception. We could allow a RETURN without argument in PL/pgSQL, if you just want to exit early. That syn

Re: [HACKERS] SQL procedures

On 10/31/17 14:23, Tom Lane wrote: > Putting 0 in prorettype seems like a pretty bad idea. It seemed like the natural thing to do, since we use a zero OID to indicate "nothing" in many other places. > Why not use VOIDOID for the prorettype value? We need a way to distinguish functions that are c

Re: [HACKERS] SQL procedures

On 31 October 2017 at 17:23, Peter Eisentraut wrote: > I've been working on SQL procedures. (Some might call them "stored > procedures", but I'm not aware of any procedures that are not stored, so > that's not a term that I'm using here.) Looks good > Everything that follows is intended to alig

Re: [HACKERS] SQL/JSON in PostgreSQL

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 > has rotten. Could you send a

Re: [HACKERS] SQL/JSON in PostgreSQL

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 feature for JSON query funct

Re: [HACKERS] SQL/JSON in PostgreSQL

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 o

Re: [HACKERS] SQL/JSON in PostgreSQL

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) - > https://github.com/postgrespro/sqljson/

Re: [HACKERS] SQL/JSON in PostgreSQL

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 to the patch, and found some issues,

Re: [HACKERS] SQL/JSON in PostgreSQL

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 procedures

2017-10-31 18:23 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > I've been working on SQL procedures. (Some might call them "stored > procedures", but I'm not aware of any procedures that are not stored, so > that's not a term that I'm using here.) > > Everything that follows is

Re: [HACKERS] SQL procedures

2017-10-31 18:23 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > I've been working on SQL procedures. (Some might call them "stored > procedures", but I'm not aware of any procedures that are not stored, so > that's not a term that I'm using here.) > > Everything that follows is

Re: [HACKERS] SQL procedures

Peter Eisentraut writes: > I've been working on SQL procedures. No comment yet on the big picture here, but ... > The provided procedural languages (an ever more > confusing term) each needed a small touch-up to handle pg_proc entries > with prorettype == 0. Putting 0 in prorettype seems like a

Re: [HACKERS] SQL procedures

On 31 October 2017 at 18:23, Peter Eisentraut wrote: > I've been working on SQL procedures. (Some might call them "stored > procedures", but I'm not aware of any procedures that are not stored, so > that's not a term that I'm using here.) I guess that the DO command might have a variant to allo

Re: [HACKERS] SQL/JSON in PostgreSQL

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: =# C

Re: [HACKERS] SQL/JSON in PostgreSQL

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 now. Is it last version? >>> >>> Regards >>> >>> Pavel >>> >>> Yes, this is

Re: [HACKERS] SQL/JSON in PostgreSQL

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 now. Is it last version? >>> >>> Regards >>> >>> Pavel >>> >>> Yes, this is

Re: [HACKERS] SQL/JSON in PostgreSQL

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 >> unfinished WIP >> patch no. 9, but I think it sh

Re: [HACKERS] SQL/JSON in PostgreSQL

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 Thank you Pavel -- > Ni

Re: [HACKERS] SQL/JSON in PostgreSQL

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 mailto:robertmh...@gmail.com>> wrote: On Fri, Sep 1

Re: [HACKERS] SQL/JSON in PostgreSQL

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: >>> Can we expect a rebased version of this patch for this commitfest?

Re: [HACKERS] SQL/JSON in PostgreSQL

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, js

Re: [HACKERS] SQL/JSON in PostgreSQL

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 Herrerahttps://www.2ndQuadrant.c

Re: [HACKERS] SQL/JSON in PostgreSQL

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, Sep 15, 2017 at 10:10 AM, Daniel Gustafsson >>> wrote: >>> Can we

Re: [HACKERS] SQL/JSON in PostgreSQL

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 a rebased version of this patch for this commitfest? >>> Since it’

Re: [HACKERS] SQL/JSON in PostgreSQL

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 as early as we can in >> the >> process.

Re: [HACKERS] SQL/JSON in PostgreSQL

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 and hasn't been upd

Re: [HACKERS] SQL/JSON in PostgreSQL

> 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 major rebase. Can we expect a rebase

Re: [HACKERS] SQL/JSON in PostgreSQL

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, 24x7

Re: [HACKERS] [SQL] Postgresql “alter column type” creates an event which contains “temp_table_xxx”

=?UTF-8?B?WmVocmEgR8O8bCDDh2FidWs=?= writes: > => ALTER TABLE test ALTER COLUMN x TYPE integer USING > (trim(x)::integer);ALTER TABLE > Last command I've executed to alter column data type creates an event like > this: > BEGIN 500913table public.pg_temp_1077668: INSERT: x[integer]:14table > publi

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 9:52 AM, Jan de Visser wrote: > I am not quite sure what you're trying to achieve, but are you aware that > pgsql 9.6 introduced the ON CONFLICT clause, which allows you to do the same > with a different syntax? > > https://www.postgresql.org/docs/9.6/static/sql-insert.html

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 3:13 PM, Michael Paquier wrote: > On Thu, Jun 22, 2017 at 5:30 PM, Kang Yuzhe wrote: >> I wish I could but it's because I don't believe that I have the right >> capability to fix code conflicts. My ultimate goal is to be PG hacker >> like YOU. Anyway, I will consider your

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 7:52 PM, Jan de Visser wrote: > On Thursday, June 22, 2017 12:32:14 PM EDT Kang Yuzhe wrote: >> Here is a sample what I did after applying the patch. >> >> testdb=# BEGIN; >> BEGIN >> testdb=# >> testdb=# MERGE INTO Stock USING Buy ON Stock.item_id = Buy.item_id >> testdb-#

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thursday, June 22, 2017 12:32:14 PM EDT Kang Yuzhe wrote: > Here is a sample what I did after applying the patch. > > testdb=# BEGIN; > BEGIN > testdb=# > testdb=# MERGE INTO Stock USING Buy ON Stock.item_id = Buy.item_id > testdb-# WHEN MATCHED THEN UPDATE SET balance = balance + Buy.volume >

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 3:51 PM, Peter Eisentraut wrote: > On 6/22/17 05:13, Craig Ringer wrote: >> On 22 June 2017 at 17:00, Kang Yuzhe wrote: >> >>> diff --git a/src/backend/executor/nodeModifyTable.c >>> b/src/backend/executor/nodeModifyTable.c >>> index 8619ce3..e3ac758 100644 >>> --- a/src/b

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 12:10 PM, Thomas Munro wrote: > On Thu, Jun 22, 2017 at 9:00 PM, Kang Yuzhe wrote: >> I just downloaded the patch from GSoC site. > > I just looked at > https://wiki.postgresql.org/wiki/Add_MERGE_command_GSoC_2010 and saw > that the file https://wiki.postgresql.org/wiki/Fi

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On 6/22/17 05:13, Craig Ringer wrote: > On 22 June 2017 at 17:00, Kang Yuzhe wrote: > >> diff --git a/src/backend/executor/nodeModifyTable.c >> b/src/backend/executor/nodeModifyTable.c >> index 8619ce3..e3ac758 100644 >> --- a/src/backend/executor/nodeModifyTable.c >> +++ b/src/backend/executor/n

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 5:30 PM, Kang Yuzhe wrote: > I wish I could but it's because I don't believe that I have the right > capability to fix code conflicts. My ultimate goal is to be PG hacker > like YOU. Anyway, I will consider your perspective. Nice to see such a goal, though as a first patc

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On 22 June 2017 at 17:00, Kang Yuzhe wrote: > diff --git a/src/backend/executor/nodeModifyTable.c > b/src/backend/executor/nodeModifyTable.c > index 8619ce3..e3ac758 100644 > --- a/src/backend/executor/nodeModifyTable.c > +++ b/src/backend/executor/nodeModifyTable.c The first entry in the 'index

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 9:00 PM, Kang Yuzhe wrote: > I just downloaded the patch from GSoC site. I just looked at https://wiki.postgresql.org/wiki/Add_MERGE_command_GSoC_2010 and saw that the file https://wiki.postgresql.org/wiki/File:Merge_v201.tar was uploaded on 24 Aug 2010. So I picked a ran

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 11:23 AM, Craig Ringer wrote: > On 22 June 2017 at 16:05, Kang Yuzhe wrote: >> Dear PG hackers, >> >> First my apology if I appear to be a jerk or not following the policy. >> >> I emailed Boxuan Zhai who was in charge of the SQL Merge keyword in >> 2010 of GSoC but witho

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 11:16 AM, Michael Paquier wrote: > On Thu, Jun 22, 2017 at 5:05 PM, Kang Yuzhe wrote: >> First my apology if I appear to be a jerk or not following the policy. > > No problem. > >> I emailed Boxuan Zhai who was in charge of the SQL Merge keyword in >> 2010 of GSoC but wit

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On 22 June 2017 at 16:05, Kang Yuzhe wrote: > Dear PG hackers, > > First my apology if I appear to be a jerk or not following the policy. > > I emailed Boxuan Zhai who was in charge of the SQL Merge keyword in > 2010 of GSoC but without reply. > > I want to apply merge_v201.patch to specific PG v

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 5:05 PM, Kang Yuzhe wrote: > First my apology if I appear to be a jerk or not following the policy. No problem. > I emailed Boxuan Zhai who was in charge of the SQL Merge keyword in > 2010 of GSoC but without reply. > > I want to apply merge_v201.patch to specific PG ver

[HACKERS] SQL MERGE patches for PostgreSQL Versions

Dear PG hackers, First my apology if I appear to be a jerk or not following the policy. I emailed Boxuan Zhai who was in charge of the SQL Merge keyword in 2010 of GSoC but without reply. I want to apply merge_v201.patch to specific PG version. It failed saying 1 or 2 of 5 hunk failed. My que

Re: [HACKERS] SQL/JSON in PostgreSQL

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 t

Re: [HACKERS] SQL/JSON in PostgreSQL

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 type

Re: [HACKERS] SQL/JSON in PostgreSQL

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 et

Re: [HACKERS] SQL/JSON in PostgreSQL

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, > maybe, > > a "currenc

Re: [HACKERS] SQL/JSON in PostgreSQL

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, > > a "currency" type). > >

Re: [HACKERS] SQL/JSON in PostgreSQL

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 h

Re: [HACKERS] SQL/JSON in PostgreSQL

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 standard, but from wh

Re: [HACKERS] SQL/JSON in PostgreSQL

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 han

Re: [HACKERS] SQL/JSON in PostgreSQL

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 JSON is well-known, universally d

Re: [HACKERS] SQL/JSON in PostgreSQL

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 slightly, I have not

Re: [HACKERS] SQL Standard Feature T211

On 3/9/17 18:39, Kevin Grittner wrote: > With the addition of transition tables we have all four, although > I'm not sure whether the CREATE TRIGGER statement conforms closely > enough to claim the feature. The two basic issues I can think of > are: > - we don't allow the OLD and NEW transition v

Re: [HACKERS] SQL/JSON in PostgreSQL

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 have not seen much interest in

Re: [HACKERS] SQL/JSON in PostgreSQL

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. Thanks

Re: [HACKERS] SQL/JSON in PostgreSQL

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 fix.

[HACKERS] SQL Standard Feature T211

[separate thread from transition table patch, since a different audience might be interested] Four things are required to claim support for Feature T211, "Basic trigger capability": - support for the CREATE TRIGGER statement - the ability to declare and reference transition tables for AFTER t

Re: [HACKERS] SQL/JSON in PostgreSQL

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

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 wrote

Re: [HACKERS] SQL/JSON in PostgreSQL

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 irrel

Re: [HACKERS] SQL/JSON in PostgreSQL

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 support though

Re: [HACKERS] SQL/JSON in PostgreSQL

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 subset of itself:

Re: [HACKERS] SQL/JSON in PostgreSQL

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 -- Sen

Re: [HACKERS] SQL/JSON in PostgreSQL

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 and as the standard be

Re: [HACKERS] SQL/JSON in PostgreSQL

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 world of configur

Re: [HACKERS] SQL/JSON in PostgreSQL

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 datetime issue: as

Re: [HACKERS] SQL/JSON in PostgreSQL

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 >> reviewing patches an

Re: [HACKERS] SQL/JSON in PostgreSQL

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 date(time) serializatio

Re: [HACKERS] SQL/JSON in PostgreSQL

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 ear

Re: [HACKERS] SQL/JSON in PostgreSQL

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 had

Re: [HACKERS] SQL/JSON in PostgreSQL

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 on

Re: [HACKERS] SQL/JSON in PostgreSQL

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 standard (ISO/IEC 9075-2:2016(E)), which was publis

Re: [HACKERS] SQL/JSON in PostgreSQL

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 9075-2:2016(E)), which was published > >

Re: [HACKERS] SQL/JSON in PostgreSQL

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 for purchase from ISO we

Re: [HACKERS] SQL/JSON in PostgreSQL

> > > >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 PostgreSQL

Re: [HACKERS] SQL/JSON in PostgreSQL

> > >>> >> 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

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 was published 2016-12-15 and is >> available on

Re: [HACKERS] SQL/JSON in PostgreSQL

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 ( > https://www.iso.org/standard/635

[HACKERS] SQL/JSON in PostgreSQL

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 ( https://www.iso.org/standard/63556.html). Unfortunately I didn't find any public sources of t

Re: [HACKERS] "SQL sentence"?

On 2/17/17 10:46 PM, Alvaro Herrera wrote: Sure. We have the extension that turned the command into JSON. It's still an unfinished patch, sadly, even though Alex Shulgin spent a lot of effort trying to get it finished. It is still missing a nontrivial amount of work, but within reach ISTM. Y

Re: [HACKERS] "SQL sentence"?

On 2/17/17 10:46 PM, Alvaro Herrera wrote: Jim Nasby wrote: On 2/17/17 10:19 PM, Alvaro Herrera wrote: (FWIW, I'm wondering because I was just looking to see why there's no details for things like altering a column in a table.) Do you mean you want to have access to the details of the alter ta

Re: [HACKERS] "SQL sentence"?

Jim Nasby wrote: > On 2/17/17 10:19 PM, Alvaro Herrera wrote: > > > (FWIW, I'm wondering because I was just looking to see why there's no > > > details for things like altering a column in a table.) > > Do you mean you want to have access to the details of the alter table > > operations being execu

Re: [HACKERS] "SQL sentence"?

On 2/17/17 10:19 PM, Alvaro Herrera wrote: (FWIW, I'm wondering because I was just looking to see why there's no details for things like altering a column in a table.) Do you mean you want to have access to the details of the alter table operations being executed? There's no structured data for

Re: [HACKERS] "SQL sentence"?

Jim Nasby wrote: > I'm confused by this: > > "pg_event_trigger_ddl_commands returns one row for each base command > executed; some commands that are a single SQL sentence may return more than > one row." > > What is a "SQL sentence"? I meant "a single SQL command". The word "sentence" probably

[HACKERS] "SQL sentence"?

I'm confused by this: "pg_event_trigger_ddl_commands returns one row for each base command executed; some commands that are a single SQL sentence may return more than one row." What is a "SQL sentence"? (FWIW, I'm wondering because I was just looking to see why there's no details for things

Re: [HACKERS] SQL access to access method details

On Mon, Mar 28, 2016 at 11:02 PM, Jim Nasby wrote: > While working on a tool to capture catalog/stats info and looking at cross > version compatibility, I noticed that the pg_am changes removed SQL access > to a bunch of AM info. [1] indicates that's part of the purpose of the > patch; are we sur

[HACKERS] SQL access to access method details

While working on a tool to capture catalog/stats info and looking at cross version compatibility, I noticed that the pg_am changes removed SQL access to a bunch of AM info. [1] indicates that's part of the purpose of the patch; are we sure no tools are using this info? Unlike previous catalog c

  1   2   3   4   5   6   7   8   9   10   >