Re: [HACKERS] new json funcs

2014-01-28 Thread Josh Berkus
On 01/27/2014 01:06 PM, Alvaro Herrera wrote: Andrew Dunstan escribió: I'm not sure I understand the need. This is the difference between the _text variants and their parents. Why would you call json_object_field when you want the dequoted text? Because I first need to know its type.

Re: [HACKERS] new json funcs

2014-01-28 Thread Alvaro Herrera
Josh Berkus wrote: On 01/27/2014 01:06 PM, Alvaro Herrera wrote: Andrew Dunstan escribió: I'm not sure I understand the need. This is the difference between the _text variants and their parents. Why would you call json_object_field when you want the dequoted text? Because I first

Re: [HACKERS] new json funcs

2014-01-28 Thread Andrew Dunstan
On 01/28/2014 01:22 PM, Alvaro Herrera wrote: Josh Berkus wrote: On 01/27/2014 01:06 PM, Alvaro Herrera wrote: Andrew Dunstan escribió: I'm not sure I understand the need. This is the difference between the _text variants and their parents. Why would you call json_object_field when you want

Re: [HACKERS] new json funcs

2014-01-28 Thread Marko Tiikkaja
Hi Andrew, On 1/24/14, 7:26 PM, Andrew Dunstan wrote: OK, here's the patch, this time with docs, thanks to Merlin Moncure and Josh Berkus for help with that. Thanks, this one is looking pretty good. A couple of small issues: - The oid 3195 of json_object_agg_transfn has been taken by a

Re: [HACKERS] new json funcs

2014-01-28 Thread Andrew Dunstan
On 01/28/2014 05:07 PM, Marko Tiikkaja wrote: Hi Andrew, On 1/24/14, 7:26 PM, Andrew Dunstan wrote: OK, here's the patch, this time with docs, thanks to Merlin Moncure and Josh Berkus for help with that. Thanks, this one is looking pretty good. A couple of small issues: - The oid 3195

Re: [HACKERS] new json funcs

2014-01-27 Thread Merlin Moncure
On Fri, Jan 24, 2014 at 3:26 PM, Josh Berkus j...@agliodbs.com wrote: On 01/24/2014 12:59 PM, Andrew Dunstan wrote: On 01/24/2014 03:40 PM, Laurence Rowe wrote: For consistency with the existing json functions (json_each, json_each_text, etc.) it might be better to add separate

Re: [HACKERS] new json funcs

2014-01-27 Thread Andrew Dunstan
On 01/27/2014 12:43 PM, Merlin Moncure wrote: On Fri, Jan 24, 2014 at 3:26 PM, Josh Berkus j...@agliodbs.com wrote: On 01/24/2014 12:59 PM, Andrew Dunstan wrote: On 01/24/2014 03:40 PM, Laurence Rowe wrote: For consistency with the existing json functions (json_each, json_each_text, etc.) it

Re: [HACKERS] new json funcs

2014-01-27 Thread Alvaro Herrera
Andrew Dunstan escribió: Note that we can only do this when the result type stays the same. It does not for json_each/json_each_text or json_extract_path/json_extract_path_text, which is why we have different functions for those cases. In C code, if I extract a value using json_object_field

Re: [HACKERS] new json funcs

2014-01-27 Thread Andrew Dunstan
On 01/27/2014 03:53 PM, Alvaro Herrera wrote: Andrew Dunstan escribió: Note that we can only do this when the result type stays the same. It does not for json_each/json_each_text or json_extract_path/json_extract_path_text, which is why we have different functions for those cases. In C code,

Re: [HACKERS] new json funcs

2014-01-27 Thread Alvaro Herrera
Andrew Dunstan escribió: I'm not sure I understand the need. This is the difference between the _text variants and their parents. Why would you call json_object_field when you want the dequoted text? Because I first need to know its type. Sometimes it's an array, or an object, or a boolean,

Re: [HACKERS] new json funcs

2014-01-24 Thread Andrew Dunstan
On 01/22/2014 12:49 PM, Andrew Dunstan wrote: On 01/21/2014 06:21 PM, Marko Tiikkaja wrote: Hi Andrew, On 1/18/14, 10:05 PM, I wrote: But I'll continue with my review now that this has been sorted out. Sorry about the delay. I think the API for the new functions looks good. They are all

Re: [HACKERS] new json funcs

2014-01-24 Thread Laurence Rowe
For consistency with the existing json functions (json_each, json_each_text, etc.) it might be better to add separate json_to_record_text and json_to_recordset_text functions in place of the nested_as_text parameter to json_to_record and json_to_recordset. On 24 January 2014 10:26, Andrew

Re: [HACKERS] new json funcs

2014-01-24 Thread Andrew Dunstan
On 01/24/2014 03:40 PM, Laurence Rowe wrote: For consistency with the existing json functions (json_each, json_each_text, etc.) it might be better to add separate json_to_record_text and json_to_recordset_text functions in place of the nested_as_text parameter to json_to_record and

Re: [HACKERS] new json funcs

2014-01-24 Thread Josh Berkus
On 01/24/2014 12:59 PM, Andrew Dunstan wrote: On 01/24/2014 03:40 PM, Laurence Rowe wrote: For consistency with the existing json functions (json_each, json_each_text, etc.) it might be better to add separate json_to_record_text and json_to_recordset_text functions in place of the

Re: [HACKERS] new json funcs

2014-01-22 Thread Andrew Dunstan
On 01/21/2014 06:21 PM, Marko Tiikkaja wrote: Hi Andrew, On 1/18/14, 10:05 PM, I wrote: But I'll continue with my review now that this has been sorted out. Sorry about the delay. I think the API for the new functions looks good. They are all welcome additions to the JSON family. The

Re: [HACKERS] new json funcs

2014-01-21 Thread Marko Tiikkaja
Hi Andrew, On 1/18/14, 10:05 PM, I wrote: But I'll continue with my review now that this has been sorted out. Sorry about the delay. I think the API for the new functions looks good. They are all welcome additions to the JSON family. The implementation side looks reasonable to me. I'm

Re: [HACKERS] new json funcs

2014-01-21 Thread Andrew Dunstan
On 01/21/2014 06:21 PM, Marko Tiikkaja wrote: Hi Andrew, On 1/18/14, 10:05 PM, I wrote: But I'll continue with my review now that this has been sorted out. Sorry about the delay. I think the API for the new functions looks good. They are all welcome additions to the JSON family. The

Re: [HACKERS] new json funcs

2014-01-18 Thread Marko Tiikkaja
On 2014-01-17 03:08, Andrew Dunstan wrote: In case anyone feels like really nitpicking, this version fixes some pgindent weirdness due to an outdated typedef list in the previous version. Is it possible for you to generate a diff that doesn't have all these unrelated changes in it (from a

Re: [HACKERS] new json funcs

2014-01-18 Thread Andrew Dunstan
On 01/18/2014 12:34 PM, Marko Tiikkaja wrote: On 2014-01-17 03:08, Andrew Dunstan wrote: In case anyone feels like really nitpicking, this version fixes some pgindent weirdness due to an outdated typedef list in the previous version. Is it possible for you to generate a diff that doesn't

Re: [HACKERS] new json funcs

2014-01-18 Thread Marko Tiikkaja
On 1/18/14, 9:38 PM, Andrew Dunstan wrote: On 01/18/2014 12:34 PM, Marko Tiikkaja wrote: Is it possible for you to generate a diff that doesn't have all these unrelated changes in it (from a pgindent run, I presume)? I just read through three pagefuls and I didn't see any relevant changes, but

Re: [HACKERS] new json funcs

2014-01-16 Thread Peter Eisentraut
On 1/3/14, 9:00 PM, Andrew Dunstan wrote: Here is a patch for the new json functions I mentioned a couple of months ago. These are: json_to_record json_to_recordset json_object json_build_array json_build_object json_object_agg So far there are no docs, but

Re: [HACKERS] new json funcs

2014-01-16 Thread Andrew Dunstan
On 01/16/2014 01:57 PM, Peter Eisentraut wrote: On 1/3/14, 9:00 PM, Andrew Dunstan wrote: Here is a patch for the new json functions I mentioned a couple of months ago. These are: json_to_record json_to_recordset json_object json_build_array json_build_object

Re: [HACKERS] new json funcs

2014-01-16 Thread Andrew Dunstan
On 01/16/2014 07:39 PM, Andrew Dunstan wrote: On 01/16/2014 01:57 PM, Peter Eisentraut wrote: On 1/3/14, 9:00 PM, Andrew Dunstan wrote: Here is a patch for the new json functions I mentioned a couple of months ago. These are: json_to_record json_to_recordset json_object

Re: [HACKERS] new json funcs

2014-01-10 Thread Alvaro Herrera
Is it just me, or is the json_array_element(json, int) function not documented? (Not a bug in this patch, I think ...) -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] new json funcs

2014-01-10 Thread Andrew Dunstan
On 01/10/2014 12:42 PM, Alvaro Herrera wrote: Is it just me, or is the json_array_element(json, int) function not documented? (Not a bug in this patch, I think ...) As discussed at the time, we didn't document the functions underlying the json operators, just the operators themselves.

Re: [HACKERS] new json funcs

2014-01-10 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: On 01/10/2014 12:42 PM, Alvaro Herrera wrote: Is it just me, or is the json_array_element(json, int) function not documented? As discussed at the time, we didn't document the functions underlying the json operators, just the operators themselves.

Re: [HACKERS] new json funcs

2014-01-10 Thread Andrew Dunstan
On 01/10/2014 01:27 PM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: On 01/10/2014 12:42 PM, Alvaro Herrera wrote: Is it just me, or is the json_array_element(json, int) function not documented? As discussed at the time, we didn't document the functions underlying the json

Re: [HACKERS] new json funcs

2014-01-10 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: On 01/10/2014 01:27 PM, Tom Lane wrote: See commits 94133a935414407920a47d06a6e22734c974c3b8 and 908ab80286401bb20a519fa7dc7a837631f20369. OK, I can fix that I guess. Sure, just remove the DESCR comments for the functions that aren't meant to be

Re: [HACKERS] new json funcs

2014-01-10 Thread Alvaro Herrera
Tom Lane wrote: I wonder whether we should add an opr_sanity test verifying that operator implementation functions don't have their own comments? The trouble is that there are a few that are supposed to, but maybe that list is stable enough that it'd be okay to memorialize in the expected

Re: [HACKERS] new json funcs

2014-01-10 Thread Alvaro Herrera
Andrew Dunstan wrote: On 01/10/2014 12:42 PM, Alvaro Herrera wrote: Is it just me, or is the json_array_element(json, int) function not documented? As discussed at the time, we didn't document the functions underlying the json operators, just the operators themselves. Oh, I see. That's

Re: [HACKERS] new json funcs

2014-01-10 Thread Andrew Dunstan
On 01/10/2014 01:58 PM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: On 01/10/2014 01:27 PM, Tom Lane wrote: See commits 94133a935414407920a47d06a6e22734c974c3b8 and 908ab80286401bb20a519fa7dc7a837631f20369. OK, I can fix that I guess. Sure, just remove the DESCR comments for

Re: [HACKERS] new json funcs

2014-01-10 Thread Tom Lane
Alvaro Herrera alvhe...@2ndquadrant.com writes: Oh, I see. That's fine with me. From the source code it's hard to see when a SQL-callable function is only there to implement an operator, though (and it seems a bit far-fetched to suppose that the developer will think, upon seeing an

Re: [HACKERS] new json funcs

2014-01-10 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: The history here is that originally I was intending to have these functions documented, and so the descriptions were made to match the operator descriptions, so that we didn't get a failure on this test. Later we decided not to document them as

Re: [HACKERS] new json funcs

2014-01-10 Thread David Fetter
On Fri, Jan 10, 2014 at 02:39:12PM -0500, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: The history here is that originally I was intending to have these functions documented, and so the descriptions were made to match the operator descriptions, so that we didn't get a

Re: [HACKERS] new json funcs

2014-01-10 Thread Tom Lane
Alvaro Herrera alvhe...@2ndquadrant.com writes: Tom Lane wrote: I wonder whether we should add an opr_sanity test verifying that operator implementation functions don't have their own comments? The trouble is that there are a few that are supposed to, but maybe that list is stable enough

Re: [HACKERS] new json funcs

2014-01-10 Thread Andrew Dunstan
On 01/10/2014 07:16 PM, Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com writes: Tom Lane wrote: I wonder whether we should add an opr_sanity test verifying that operator implementation functions don't have their own comments? The trouble is that there are a few that are supposed to,

Re: [HACKERS] new json funcs

2014-01-10 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: Is it better to knock out the DESCR entries totally or make them read implementation of foo operator? Just delete them --- initdb is responsible for inserting that boilerplate where appropriate. regards, tom lane -- Sent

[HACKERS] new json funcs

2014-01-03 Thread Andrew Dunstan
Here is a patch for the new json functions I mentioned a couple of months ago. These are: json_to_record json_to_recordset json_object json_build_array json_build_object json_object_agg So far there are no docs, but the way these work is illustrated in the regression