Re: XML ouput for psql

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> So I imagine, if this is done fully with changes in the protocol layer,
> then certain commands like "get table schema in XML" would have to exist
> in the protocol, which doesn't seem right. Also, the XML output isn't a
> sibling of the current text/binary tuples, since an XML result is always
> a whole document, not tuple data.

I would envision a distinction comparable to the existing one between T
and D messages (RowDescription and AsciiRow, using the documentation's
names): you send the table schema first, then the data. Also note that
there is no "command" to get the T message; it comes for free whenever
a SELECT result is sent to the frontend.

> What we could perhaps consider is a family of functions like I
> illustrated, but then provide a fast-path-driven layer on the client side,
> like for large objects. Initially, the development of these mapping
> functions could take place totally in user-space.

I don't object to that as a quick-and-dirty context for prototyping work,
but I'd sure hate to see it as the production version. The fastpath
protocol is a mess, and until/unless we get it cleaned up, we ought not
increase dependency on it.

A larger point is that this is still a protocol revision; pretending it
ain't is just willful obscurantism. You can tell it's a protocol revision
because you will need to rewrite client-side libraries to take advantage
of it. If we try to look the other way and pretend it isn't one, then
we'll just be incurring pain --- the most obvious pain being that it
will be hard for those client libraries to tell whether the protocol
extension is supported or not.

The way I'd prefer to see this handled is by providing alternatives to
the printtup.c DestReceiver routines. The backend could be switched to
any desired output representation just by invoking different sets of
receiver routines. What we seem to need first is a context for doing
that, in particular a way to understand how different output formats can
be fit into the FE/BE protocol.

regards, tom lane