2012/12/12 Greg Smith <g...@2ndquadrant.com>: > On 11/20/12 8:02 PM, Craig Ringer wrote: >> >> On 11/20/2012 04:48 PM, Pavel Stehule wrote: > > >>> I don't like to see current hstore in core - It doesn't support >>> nesting, it doesn't support different datatypes, it is not well >>> supported by plpgsql >>> >> >> ... or by many client libraries, though converting hstore values to json >> notation for output usually takes care of that. > > > The more I look at this, the less comfortable I am moving forward with hand > waving this issue away. The obvious but seemingly all troublesome options: > > -Store things internally using hstore. This seems to require pulling hstore > fully into core, which has this list of issues. Outputting through a JSON > filter seems like a lot of overhead. And even if the output concerns are > addressed, if there's a problem processing the raw data with PL/pgSQL that > would be bad. I didn't think about that at all until Pavel brought it up. > > -Go back to a simpler composite type idea for storing this data. It feels > wrong to create something that looks a lot like hstore data, but isn't. > There's probably subtle display/client/processing issues in there I haven't > thought of too. > > -Try to store the data in a JSON friendly way in the first place. > > That last one seems to lead right to... > >> I can't help but suspect that hstore will be subsumed by native storage >> and indexing of json objects, since these are already widely supported >> in KV or document stores. Of course, that requires that we come to some >> agreement on how to represent literal scalars for interaction with json, >> which hasn't seen much progress. > > > If this is the Right Way to solve this problem, that's puts a serious snag > in doing something useful with Timing Events in he near future. I know > better than to try and fight against following the correct path once it's > identified. I can't claim any good expertise on client encoding/transfer > issues though; that's not a strong area for me. >
I didn't watch this discussion all time, but I don't understand why you need a complex datatypes. Maybe you can do normalization and complex data types can hold only in memory. Regards Pavel > -- > Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD > PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers