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 corehstore-specific code stays in contribhstore contrib will
createan hstore type to call contrib and core code9.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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
