Re: additional json functionality

Hannu Krosing-5 wrote
> On 11/14/2013 08:17 PM, Merlin Moncure wrote:
>> On Thu, Nov 14, 2013 at 11:34 AM, David E. Wheeler
>> <

> david@

> > wrote:
>>> On Nov 14, 2013, at 7:07 AM, Merlin Moncure <

> mmoncure@

> > wrote:
>>>
>>>> This is exactly what needs to be done, full stop (how about: hstore).
>>>> It really comes down to this: changing the serialization behaviors
>>>> that have been in production for 2 releases (three if you count the
>>>> extension) is bad enough, but making impossible some legal json
>>>> constructions which are currently possible is an unacceptable
>>>> compatibility break.

The current json format is a minimally conforming (i.e., does not enforce
the "should not contain duplicates" suggestion) structured json validating
type that stores its input as-is once validated. Its presence is going to
probably cause difficulties with function API for reasons already mentioned
but its place in core type-library is already firmly established. Andrew's
API additions seem like good things to have for this type. I haven't seen
any comments on this but do these functions facilitate creating json that
can have duplicates and that maintain order? Even if we accept input to
json with these limitations we are not obligated to make our own json output
minimally conforming - though we should at maintain such if it is already in
place.

> So my suggestion is to upgrade existing json data type to
> text - or maybe json_text with format check - when upgrading
> to 9.4, to change current function which output "json" to
> output "text" and have new "json" type which stores proper
> JavaScript Object - like structured data.

Technically a down-grade but anyway...

How does this work with a pg_dump/pg_restore upgrade?

If we want to have maximally conforming json type(s) we can still create
them. I'd say we'd still want two versions, similar in a way to how we have
"bytea" and "text" even though any text can technically be stored like
"bytea". The constructor API for both would want to be identical with the
only real difference being that text->json_source would be layout preserving
(i.e., validation only) while text->json_binary would be a true parsing
conversion. Likewise json_source->text would output the same input while
json_binary->text would output the canonical form (pretty-printing and such
would need to be initiated via functions).

If things are going to be a little more complex anyway why not just go and
toss in the kitchen sink too? This way we provide maximal flexibility.
From a development perspective some features (indexes, equality, in-place
updates and related modification API) may only make sense on a subset of the
available types but trade-offs are a fact of life.

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/additional-json-functionality-tp5777975p5778406.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.