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