Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP)

On Tue, Oct 19, 2010 at 4:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Terry Laurenzo <tj(at)laurenzo(dot)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
>

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