I am very interested in experimenting with functional indexes into JSON
structures.  I think this could be very powerful combined with full text
search as well as constraints.  It would allow for using postgres as an
unstructured data store without sacrificing the powerful indexing features,
durability, and transactional semantics that comes with using postgres or
RDBMSes in general.

One use case in particular I have been trying to solve for lately is
persisting and synchronizing client-side state (in a mobile application)
with a server.  It would be nice to have a flat, schemaless table (maybe a
table that's like (id, type, owner, data) where data would be a JSON blob).
 I could do this now without JSON support, but I think indexing inside that
JSON blob and having validation database side is valuable as well.  And as
I mentioned before, i'd rather not throw out the baby with the bathwater by
using a different type of database because ACID, replication, and
constraints are also very important to this.  As is being consistent with
the rest of our technology stack. (I'd essentially be using a relational
database to persist an object database)

I'm also not too concerned about storage consumption with this (even though
columnar compression would help a lot in the future) since it's easily
partitionable by user ID.

For my case the equivalent of postgres's XPath would work.  Also having it
as a maintained contrib module would be sufficient, although it being part
of core as XPath is would be even better.

Just my $0.02... even if I'm a bit late to the conversation.


Reply via email to