On Thu, Mar 6, 2014 at 09:33:18AM -0500, Andrew Dunstan wrote:
> I hear you, and largely agree, as long as the compatibility issue is
> solved. If it's not, I think inventing a new hstore2 type is
> probably a lousy way to go.
>
> For good or ill, the world has pretty much settled on wanting to use
> json for lightweight treeish data. That's where we'll get the most
> impact. Virtually every programming language (including Perl) has
> good support for json.
>
> I'm not sure what the constraints of json that you might want to
> break are. Perhaps you'd like to specify.
>
> Whatever we do, rest assured your work won't go to waste.
OK, just to summarize:
JSONB and everything it shares with hstore will be in core
hstore-specific code stays in contrib
hstore contrib will create an hstore type to call contrib and core code
9.4 hstore has some differences from pre-9.4
The question is whether we change/improve hstore in 9.4, or create an
hstore2 that is the improved hstore for 9.4 and keep hstore identical to
pre-9.4. That last option looks an awful like the dreaded VARCHAR2.
What can we do to help people migrate to an hstore type that supports
data types? Is there a function we can give them to flag possible
problem data, or give them some function to format things the old way
for migrations, etc. If they are going to have to rewrite all their old
data, why bother with a backward-compatible binary format? Is it only
the client applications that will need to be changed? How would we
instruct users on the necessary changes?
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
