Re: JSON for PG 9.2

Поиск
Список
Период
Сортировка
От Mike Lewis
Тема Re: JSON for PG 9.2
Дата
Msg-id CA+foqsR7mTDEBcvtXpgx49t_JEJGfXU6tBYmSDsJSQRAYSNzJg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: JSON for PG 9.2  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
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.

Thanks!
Mike

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: JSON for PG 9.2
Следующее
От: Greg Smith
Дата:
Сообщение: Re: xlog location arithmetic