On Tue, May 26, 2009 at 10:36 AM, Magnus Hagander <mag...@hagander.net> wrote:
> Dave Page wrote:
>> On Tue, May 26, 2009 at 9:52 AM, Andrew Dunstan <and...@dunslane.net> wrote:
>>> In libxml-enabled builds at least, this could presumably be done fairly
>>> easily via the XML functions, especially if we get XSLT processing into the
>>> core XML functionality as I hope we can do this release. In fact, the
>>> ability to leverage existing XML functionality to munge the output is the
>>> thing that swings me in favor of XML as the machine readable output format
>>> instead of JSON, since we don't have and aren't terribly likely to get an
>>> inbuilt JSON parser. It means we wouldn't need some external tool at all.
>
> Actually, I think a number of users would be *very* happy if we had a
> builtin JSON parser. I'm unsure on how feasible that is though.
I think it's likely that with proper design the amount of extra code
that is required to support both XML and JSON is likely to be very
small. I don't think we're going to get away without supporting XML
because there are so many people already using XML-based tools, and I
find Andrew's argument that we already have some built-in XML support
that could possibly be used to smooth the road here as well pretty
compelling.
On the other hand, XML can be a really difficult technology to work
with because it doesn't map cleanly to the data structures that most
modern scripting languages (Perl, Python, Ruby, and probably Java and
others) use. As a simple example, if you have a hash like { a => 1, b
=> 2 } (using the Perl syntax) you can map it to
<hash><a>1</a><b>2</b></hash>. That's easy to generate, but the
reverse transformation is full of error-handling cases, like
<hash><a>1</a><b>2<c/></b></hash> and <hash><a>1</a><a>2</a></hash>.
I'm sure experienced XML hackers have ways to work around these
problems, but the XML libraries I've worked with basically don't even
try to turn the thing into any sort of general-purpose data structure.
They just let you ask questions like "What is the root element? OK,
now what elements does it contain? OK, there's an <a> tag there, what
does that have inside it? Any more-deeply-nested tags?". On the
other hand, JSON is explicitly designed to serialize and deserialize
data structures of this type, and it pretty much just works, even
between completely different programming languages.
So to summarize that - if we're only going to support one
machine-readable output format, it's probably got to be XML. But if
the additional effort to also support JSON is small, which I believe
to be the case, then I think it's worth doing because it's actually
better technology for this type of application. Maybe someone will
feel inspired to work up a contrib/json.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
