On 11/13/2013 01:37 AM, Andrew Dunstan wrote:
>
> On 11/12/2013 01:35 PM, Teodor Sigaev wrote:
>> Hi!
>>
>> Attatched patch adds nesting feature, types (string, boll and numeric
>> values), arrays and scalar to hstore type.
>>
>> All new features are described in PGConf.EU talk
>> http://www.sai.msu.su/~megera/postgres/talks/hstore-dublin-2013.pdf
>> (since PGCon some features was added).
>>
>> Patch includes:
>> 1 implementaion SRF_RETURN_NEXT_NULL()
>> 2 contrib/hstore changes
>> 3 docs of new hstore module (many thanks to David E. Wheeler
>> <david.wheeler@pgexperts.com>)
>>
>> In current state patch is in WIP status, for short period I plan to
>> move support of binary nested structure to core to share binary
>> representation for hstore and json types.
>>
>>
>>
>
> Thanks, Teodor.
>
> As soon as we have that shared binary representation available, I will
> be working on adapting it to JSON.
As I remember from earlier discussions, current json has some
artefacts that some people want to preserve and which are incompatible
with hstore approach where you have actual object behind the serialisation.
I remember strong voices in support of *not* normalising json, so that
things like
{"a":1,"a":true, "a":"b", "a":none}
would go through the system unaltered, for claimed standard usage of
json as
"processing instructions". That is as source code which can possibly
converted
to JavaScript Object and not something that would come out of
serialising of
any existing JavaScript Object.
I suggest we add another type, maybe jsobj, which has input and output
as standard"JSON" but which is defined from the start to be equivalent of existing
object
and not "preservable source code" to such object.
Cheers
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ
