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 of
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 rec
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
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?
> >
> >
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 t
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/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ó:
> 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_fie
On 01/27/2014 12:43 PM, Merlin Moncure wrote:
On Fri, Jan 24, 2014 at 3:26 PM, Josh Berkus 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 t
On Fri, Jan 24, 2014 at 3:26 PM, Josh Berkus 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
>>> json_to_record_te
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/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 json_to_rec
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 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
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 imp
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 imp
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 no
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 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 hav
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 pgin
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
j
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
json
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
Andrew Dunstan 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 via pgsql-hackers
On 01/10/2014 07:16 PM, Tom Lane wrote:
Alvaro Herrera 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 st
Alvaro Herrera 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 that it'd be okay t
On Fri, Jan 10, 2014 at 02:39:12PM -0500, Tom Lane wrote:
> Andrew Dunstan 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 tes
Andrew Dunstan 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 part of last releas
Alvaro Herrera 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 undocumented function, "oh thi
On 01/10/2014 01:58 PM, Tom Lane wrote:
Andrew Dunstan 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 a
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.
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 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 used directly.
I
On 01/10/2014 01:27 PM, Tom Lane wrote:
Andrew Dunstan 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 oper
Andrew Dunstan 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.
I see though
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.
ch
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 (pgsql-hackers@p
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
38 matches
Mail list logo
