Re: additional json functionality

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Hannu Krosing <hannu(at)2ndquadrant(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Teodor Sigaev <teodor(at)sigaev(dot)ru>
Subject: Re: additional json functionality
Date: 2013-11-14 16:06:20
Message-ID: CAHyXU0zp73wPxY_r-XnEQvCz85MWDkRUg9zDFZ536bJrj4J2GQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 14, 2013 at 9:42 AM, Hannu Krosing <hannu(at)2ndquadrant(dot)com> wrote:
> This is supported by the fact that current functions on json-source
> treat it as json-object (for example key lookup gives you the value
> of latest key and not a list of all matching key values).

yeah. hm. that's a good point.

Maybe there's a middle ground here: I bet the compatibility issues
would be minimized to an acceptable level if the 'xxx_to_json'
functions maintained their current behaviors; they would construct the
json type in a special internal mode that would behave like the
current type does. In other words, the marshalling into binary
structure could happen when:

*) stored do a column in a table
*) when any modifying routine is called, updating a key, value, etc
*) manually via a function

but not at cast time. This preserves compatibility for the important
points and allows serialization of structures that are difficult with
the binary mode variant.

merln

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhan Li 2013-11-14 16:35:10 Ideas of "printing out" the alternative paths
Previous Message Hannu Krosing 2013-11-14 15:46:56 Re: additional json functionality