On Wed, Feb 5, 2014 at 12:44 AM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > send/recv functions are also needed for binary-format COPY. IMHO jsonb must > have send/recv functions. All other built-in types have them, except for > types like 'smgr', 'aclitem' and 'any*' that no-one should be using as > column types.
Yes -- completely agree. I also consider the hstore functionality (in particular, searching and access operators) to be essential functionality. I'm actually surprised we have an alternate binary wire format for jsonb at all; json is explicitly text and I'm not sure what the use case of sending the internal structure is. Meaning, maybe jsonb send/recv should be a thin wrapper to sending the json string. The hstore send/recv I think properly covers the case where client side binary wire format actors would want to manage performance critical cases that want to avoid parsing. On Wed, Feb 5, 2014 at 1:21 AM, Oleg Bartunov <obartu...@gmail.com> wrote: > Andrew provided us more information and we'll work on recv. What > people think about testing this stuff ? btw, we don't have any > regression test on this. I'm intensely interested in this work; I consider it to be transformative. I've *lightly* tested the jsonb/hstore functionality and so far everything is working. I still have concerns about the API. Aside from the stuff I mentioned upthread I find the API split between jsonb and hstore to be a little odd; a lot of useful bits (for example, the @> operator) come via the hstore type only. So these types are joined at the hip for real work which makes the diverging incomplete behaviors in functions like populate_record() disconcerting. Another point I'm struggling with is what jsonb brings to the table that isn't covered either hstore or json; working through a couple of cases I find myself not using the jsonb functionality except as a 'hstore json formatter' which the json type covers. I'm probably being obtuse, but we have to be cautious before plonking a couple of dozen extra functions in the public schema. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
