Tom Lane writes:
> This is also a good time to stop and ask whether the frontend/backend
> protocol needs to change to support this. Not having read the spec,
> I have no idea what the low-level transport needs are for XML output,
> but I suspect our present protocol is not it ...
The spec defines "mappings" between tables, schemas, and catalogs on the
one side and each time a pair of XML documents on the other side, one of
which is an XML schema document (sort of a document type declaration) and
the other is an XML data document that follows the constraints of the
schema document and contains the actual data. A table could of course
more or less be interpreted to mean a query result. That means, this
functionality provides both query result retrieval via XML and a pg_dump
type mechanism with XML output.
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.
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.
--
Peter Eisentraut peter_e@gmx.net
