From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Hannu Krosing <hannu(at)krosing(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: json accessors |
Date: | 2012-11-30 15:59:44 |
Message-ID: | 50B8D7F0.5040603@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/30/2012 04:29 PM, Andrew Dunstan wrote:
>
> On 11/30/2012 10:04 AM, Hannu Krosing wrote:
>>>
>>>
>>> OK, so based on this discussion, I'm thinking of the following:
>>>
>>> * keep the original functions and operators. json_keys is still
>>> required for the case where the json is not flat.
>>> * json_each(json) => setof (text, text)
>>> errors if the json is not a flat object
>>
>> Why not json_each(json) => setof (text, json) ? with no erroring out ?
>>
>> if the json does represent text it is easy to convert to text on the
>> query side.
>
>
> Well, it would be possible, sure. I'm not sure how useful. Or we could
> do both fairly easily. It's not as simple or efficient as you might
> think to dequote / de-escape json string values, which is why the
> original API had variants for returning both types of values. Maybe we
> need a function for doing just that.
>
Btw, how does current json type handle code pages - is json always utf-8
even when server encoding is not ?
if so then we could at least have a shortcut conversion of json to
utf8-text which can skip codepage changes.
----------------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2012-11-30 16:29:06 | Re: [PATCH] Patch to fix a crash of psql |
Previous Message | Andres Freund | 2012-11-30 15:58:02 | Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger? |