On 30.05.2017 02:31, Tom Lane wrote:
Nikita Glukhov writes:
2. Also I've found a some kind of thinko in JsGetObjectSize() macro, but it
seems that this obvious mistake can not lead to incorrect behavior.
Hm, I think it actually was wrong for the case of jsonb_cont == NULL,
wasn't it?
Yes, J
Noah Misch writes:
> On Mon, May 22, 2017 at 10:19:37PM +0300, Nikita Glukhov wrote:
>> Attached two small fixes for the previous committed patch:
> [Action required within three days. This is a generic notification.]
> The above-described topic is currently a PostgreSQL 10 open item. Andrew,
On Mon, May 22, 2017 at 10:19:37PM +0300, Nikita Glukhov wrote:
> Attached two small fixes for the previous committed patch:
>
> 1. I've noticed a difference in behavior between json_populate_record()
> and jsonb_populate_record() if we are trying to populate record from a
> non-JSON-object: json
Nikita Glukhov writes:
> Attached two small fixes for the previous committed patch:
> 1. I've noticed a difference in behavior between json_populate_record()
> and jsonb_populate_record() if we are trying to populate record from a
> non-JSON-object: json function throws an error but jsonb functi
Attached two small fixes for the previous committed patch:
1. I've noticed a difference in behavior between json_populate_record()
and jsonb_populate_record() if we are trying to populate record from a
non-JSON-object: json function throws an error but jsonb function returns
a record with NULL f
On 04/05/2017 07:24 PM, Andrew Dunstan wrote:
>
> OK, I have been through this and I think it's basically committable. I
> am currently doing some cleanup, such as putting all the typedefs in one
> place, fixing redundant comments and adding more comments, declaring all
> the static functions, an
On 04/04/2017 05:18 PM, Andrew Dunstan wrote:
>
> On 04/03/2017 05:17 PM, Andres Freund wrote:
>> On 2017-03-21 14:31:08 -0400, Andrew Dunstan wrote:
>>> On 03/21/2017 01:37 PM, David Steele wrote:
On 3/16/17 11:54 AM, David Steele wrote:
> On 2/1/17 12:53 AM, Michael Paquier wrote:
On 04/03/2017 05:17 PM, Andres Freund wrote:
> On 2017-03-21 14:31:08 -0400, Andrew Dunstan wrote:
>>
>> On 03/21/2017 01:37 PM, David Steele wrote:
>>> On 3/16/17 11:54 AM, David Steele wrote:
On 2/1/17 12:53 AM, Michael Paquier wrote:
> On Thu, Jan 26, 2017 at 6:49 AM, Tom Lane wrote:
On 2017-03-21 14:31:08 -0400, Andrew Dunstan wrote:
>
>
> On 03/21/2017 01:37 PM, David Steele wrote:
> > On 3/16/17 11:54 AM, David Steele wrote:
> >> On 2/1/17 12:53 AM, Michael Paquier wrote:
> >>> On Thu, Jan 26, 2017 at 6:49 AM, Tom Lane wrote:
> Nikita Glukhov writes:
> > On 25.01.
On 22.03.2017 00:26, David Steele wrote:
On 3/21/17 2:31 PM, Andrew Dunstan wrote:
On 03/21/2017 01:37 PM, David Steele wrote:
>>
This thread has been idle for months since Tom's review.
The submission has been marked "Returned with Feedback". Please feel
free to resubmit to a future commitf
On 3/21/17 2:31 PM, Andrew Dunstan wrote:
On 03/21/2017 01:37 PM, David Steele wrote:
>>
This thread has been idle for months since Tom's review.
The submission has been marked "Returned with Feedback". Please feel
free to resubmit to a future commitfest.
Please revive. I am planning to loo
On 03/21/2017 01:37 PM, David Steele wrote:
> On 3/16/17 11:54 AM, David Steele wrote:
>> On 2/1/17 12:53 AM, Michael Paquier wrote:
>>> On Thu, Jan 26, 2017 at 6:49 AM, Tom Lane wrote:
Nikita Glukhov writes:
> On 25.01.2017 23:58, Tom Lane wrote:
>> I think you need to take a seco
On 3/16/17 11:54 AM, David Steele wrote:
On 2/1/17 12:53 AM, Michael Paquier wrote:
On Thu, Jan 26, 2017 at 6:49 AM, Tom Lane wrote:
Nikita Glukhov writes:
On 25.01.2017 23:58, Tom Lane wrote:
I think you need to take a second look at the code you're producing
and realize that it's not so c
On 2/1/17 12:53 AM, Michael Paquier wrote:
> On Thu, Jan 26, 2017 at 6:49 AM, Tom Lane wrote:
>> Nikita Glukhov writes:
>>> On 25.01.2017 23:58, Tom Lane wrote:
I think you need to take a second look at the code you're producing
and realize that it's not so clean either. This extract f
On Thu, Jan 26, 2017 at 6:49 AM, Tom Lane wrote:
> Nikita Glukhov writes:
>> On 25.01.2017 23:58, Tom Lane wrote:
>>> I think you need to take a second look at the code you're producing
>>> and realize that it's not so clean either. This extract from
>>> populate_record_field, for example, is pr
Nikita Glukhov writes:
> On 25.01.2017 23:58, Tom Lane wrote:
>> I think you need to take a second look at the code you're producing
>> and realize that it's not so clean either. This extract from
>> populate_record_field, for example, is pretty horrid:
> But what if we introduce some helper mac
On 25.01.2017 23:58, Tom Lane wrote:
I think you need to take a second look at the code you're producing
and realize that it's not so clean either. This extract from
populate_record_field, for example, is pretty horrid:
But what if we introduce some helper macros like this:
#define JsValueIsN
Nikita Glukhov writes:
> On 22.01.2017 21:58, Tom Lane wrote:
>> 5. The business with having some arguments that are only for json and
>> others that are only for jsonb, eg in populate_scalar(), also makes me
>> itch.
> I've refactored json/jsonb passing using new struct JsValue which contains
>
Nikita Glukhov writes:
> On 22.01.2017 21:58, Tom Lane wrote:
>> If you want such macros I think it would be better to submit a separate
>> cosmetic patch that tries to hide such bit-tests behind macros throughout
>> the jsonb code.
> I've attached that patch, but not all the bit-tests were hidde
On 22.01.2017 21:58, Tom Lane wrote:
In the meantime, we are *not* going to have attndims be semantically
significant in just this one function. Therefore, please remove this patch's
dependence on attndims.
Ok, I've removed patch's dependence on attndims. But I still believe that
someday Post
Nikita Glukhov writes:
> On 01/08/2017 09:52 PM, Tom Lane wrote:
>> ... attndims is really syntactic sugar only and doesn't affect anything
>> meaningful semantically.
> I have fixed the first patch: when the number of dimensionsis unknown
> we determine it simply by the number of successive open
On 01/08/2017 09:52 PM, Tom Lane wrote:
The example you quoted at the start of the thread doesn't fail for me
in HEAD, so I surmise that it's falling foul of some assertion you added
in the 0001 patch, but if so I think that assertion is wrong. attndims
is really syntactic sugar only and doesn'
Nikita Glukhov writes:
> [ 0001_recursive_json_populate_record_v02.patch ]
> [ 0002_assign_ndims_to_record_function_result_types_v02.patch ]
I do not see the point of the second one of these, and it adds no test
case showing why it would be needed. The example you quoted at the
start of the thre
> I've noticed that this patch is on CF and needs a reviewer so I decided
> to take a look. Code looks good to me in general, it's well covered by
> tests and passes `make check-world`.
Thanks for your review.
> However it would be nice to have a little more comments. In my opinion
> every proce
Hello.
I've noticed that this patch is on CF and needs a reviewer so I decided
to take a look. Code looks good to me in general, it's well covered by
tests and passes `make check-world`.
However it would be nice to have a little more comments. In my opinion
every procedure have to have at least a
On Tue, Dec 13, 2016 at 9:38 AM, Nikita Glukhov wrote:
> It also fixes the following errors/inconsistencies caused by lost quoting of
> string json values:
>
> [master]=# select * from json_to_record('{"js": "a"}') as rec(js json);
> ERROR: invalid input syntax for type json
> DETAIL: Token "a"
Hi.
The first attached patch implements recursive processing of nested
objects and arrays in json[b]_populate_record[set](),
json[b]_to_record[set](). See regression tests for examples.
It also fixes the following errors/inconsistencies caused by lost
quoting of string json values:
[master
27 matches
Mail list logo
