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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers