On Mon, Dec 12, 2011 at 7:58 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Dec 5, 2011 at 3:12 PM, Bruce Momjian <br...@momjian.us> wrote: >> Where are we with adding JSON for Postgres 9.2? We got bogged down in >> the data representation last time we discussed this. > > We're waiting for you to send a patch that resolves all > previously-raised issues. :-) > > In all seriousness, I think the right long-term answer here is to have > two data types - one that simply validates JSON and stores it as text, > and the other of which uses some binary encoding. The first would be > similar to our existing xml datatype and would be suitable for cases > when all or nearly all of your storage and retrieval operations will > be full-column operations, and the json types is basically just > providing validation. The second would be optimized for pulling out > (or, perhaps, replacing) pieces of arrays or hashes, but would have > additional serialization/deserialization overhead when working with > the entire value. As far as I can see, these could be implemented > independently of each other and in either order, but no one seems to > have yet found the round tuits.
Rather than fuss with specific data formats, why not implement something a little more useful? At present we can have typmods passed as a cstring, so it should be possible to add typmods onto the TEXT data type. e.g. TEXT('JSON'), TEXT('JSONB') We then invent a new catalog table called pg_text_format which has oid PRIMARY KEY textformatname UNIQUE textformatvalidationproc textformatstorageproc The typmod must reduce to a single integer, so we just store the integer. If no typmod, we store 0, so we have a fastpath for normal TEXT datatypes. This would then allow people to have variations of the TEXT type that supports conversions, casts, indexing etc without additional fuss and without everything else outside the database breaking because it doesn't know that datatype name. We could then support JSON (both kinds), YAML, etc as well as providing a way to add validation into the datatype itself. We can replace citext with TEXT('CASE_INSENSITIVE') Think of this as using the object-relational capabilities of Postgres to extend the TEXT data type. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers