On Tue, Oct 19, 2010 at 4:51 PM, Tom Lane
<tgl@sss.pgh.pa.us> wrote:
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.
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
I don't think anyone here was really presenting arguments as yet. We're several layers deep on speculation and everyone is saying that experimentation is needed.
I've got my own reasons for going down this path for a solution I have in mind. I had thought that some part of that might have been applicable to pg core, but if not, that's no problem. For my own edification, I'm going to proceed down this path and see where it leads. I'll let the list know what I find out.
I can understand the sentiment that JSON should be JSON and nothing else from a traditional database server's point of view, but there is nothing sacrosanct about it in the broader context.
Terry
