Re: jsonb and nested hstore
От | Andrew Dunstan |
---|---|
Тема | Re: jsonb and nested hstore |
Дата | |
Msg-id | 52F26D1C.1000102@dunslane.net обсуждение исходный текст |
Ответ на | Re: jsonb and nested hstore (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: jsonb and nested hstore
|
Список | pgsql-hackers |
On 02/05/2014 11:40 AM, Tom Lane wrote: > Merlin Moncure <mmoncure@gmail.com> writes: >> On Wed, Feb 5, 2014 at 10:22 AM, Andrew Dunstan <andrew@dunslane.net> wrote: >>> The whole reason we have jsonb is to avoid reparsing where possible >> Sure; but on the server side. The wire format is for handling client >> concerns. For example, the case you're arguing for would be for libpq >> client to extract as jsonb as binary, manipulate it on a binary level, >> then send it back as binary. I find this case to be something of a >> stretch. > I'm with Merlin in thinking that the case for exposing a binary format > to clients is pretty weak, or at least a convincing use-case has not > been shown. Given the concerns upthread about security hazards in the > patch's existing recv code, and the fact that it's already February, > switching to "binary is the same as text" may well be the most prudent > path here. > > If we do that we're going to have to live with that forever, aren't we? I don't see why there should be a convincing case for binary format for nested hstore but not for jsonb. If it were only for arbitrary libpq clietns I wouldn't bother so much. To me the main case for binary format is that some people use COPY BINARY for efficiency reasons, and I heard tell recently of someone working on that as an option for pg_dump, which seems to me worth considering. cheers andrew
В списке pgsql-hackers по дате отправления: