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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
