Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP)
От | Tom Lane |
---|---|
Тема | Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP) |
Дата | |
Msg-id | 10741.1287528705@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP) (Terry Laurenzo <tj@laurenzo.org>) |
Ответы |
Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP)
|
Список | pgsql-hackers |
Terry Laurenzo <tj@laurenzo.org> writes: > After spending a week in the morass of this, I have to say that I am less > certain than I was on any front regarding the text/binary distinction. I'll > take some time and benchmark different cases. My hypothesis is that a well > implemented binary structure and conversions will add minimal overhead in > the IO + Validate case which would be the typical in/out flow. It could be > substantially faster for binary send/receive because the validation step > could be eliminated/reduced. I think that arguments proceeding from speed of binary send/receive aren't worth the electrons they're written on, because there is nothing anywhere that says what the binary format ought to be. In the case of XML we're just using the text representation as the binary format too, and nobody's complained about that. If we were to choose to stick with straight text internally for a JSON type, we'd do the same thing, and again nobody would complain. So, if you want to make a case for using some binary internal format or other, make it without that consideration. > I'm envisioning staging this up as follows: > 1. Create a "jsontext". jsontext uses text as its internal > representation. in/out functions are essentially a straight copy or a copy > + validate. > 2. Create a "jsonbinary" type. This uses an optimized binary format for > internal rep and send/receive. in/out is a parse/transcode operation to > standard JSON text. Ugh. Please don't. JSON should be JSON, and nothing else. Do you see any other datatypes in Postgres that expose such internal considerations? regards, tom lane
В списке pgsql-hackers по дате отправления: