<div class="gmail_quote">On Tue, Oct 19, 2010 at 4:51 PM, Tom Lane <span dir="ltr"><<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Terry
Laurenzo<<a href="mailto:tj@laurenzo.org">tj@laurenzo.org</a>> writes:<br /> > After spending a week in the
morassof this, I have to say that I am less<br /> > certain than I was on any front regarding the text/binary
distinction. I'll<br /> > take some time and benchmark different cases. My hypothesis is that a well<br /> >
implementedbinary structure and conversions will add minimal overhead in<br /> > the IO + Validate case which would
bethe typical in/out flow. It could be<br /> > substantially faster for binary send/receive because the validation
step<br/> > could be eliminated/reduced.<br /><br /></div>I think that arguments proceeding from speed of binary
send/receive<br/> aren't worth the electrons they're written on, because there is nothing<br /> anywhere that says what
thebinary format ought to be. In the case of<br /> XML we're just using the text representation as the binary format
too,<br/> and nobody's complained about that. If we were to choose to stick with<br /> straight text internally for a
JSONtype, we'd do the same thing, and<br /> again nobody would complain.<br /><br /> So, if you want to make a case for
usingsome binary internal format or<br /> other, make it without that consideration.<br /><div class="im"><br /> >
I'menvisioning staging this up as follows:<br /> > 1. Create a "jsontext". jsontext uses text as its internal<br
/>> representation. in/out functions are essentially a straight copy or a copy<br /> > + validate.<br /> >
2.Create a "jsonbinary" type. This uses an optimized binary format for<br /> > internal rep and send/receive.
in/outis a parse/transcode operation to<br /> > standard JSON text.<br /><br /></div>Ugh. Please don't. JSON
shouldbe JSON, and nothing else. Do you see<br /> any other datatypes in Postgres that expose such internal
considerations?<br/><br /> regards, tom lane<br /></blockquote></div><br />I don't think anyone
herewas really presenting arguments as yet. We're several layers deep on speculation and everyone is saying that
experimentationis needed.<br /><br />I've got my own reasons for going down this path for a solution I have in mind. I
hadthought 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.<br
/><br/>I can understand the sentiment that JSON should be JSON and nothing else from a traditional database server's
pointof view, but there is nothing sacrosanct about it in the broader context.<br /><br />Terry<br /><br />