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.
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
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
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
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
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
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
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
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,
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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,
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
37 matches
Mail list logo
