Re: json accessors

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

In response to

Responses

Browse pgsql-hackers by date

  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?