We considered putting XML in psql or libpq in the past, but the problem is that interfaces like jdbc couldn't take advantage of it.
Well, you could implement it as a C UDF and use SPI. Or write it as a C client library, and use JNI. Or just provide a Java implementation -- it's not like the COPY -> XML transformation is very complex.
To restate the case:
- I don't see how this feature is useful. Perhaps I'm mistaken, but I don't think there's a lot of user demand for it (feel free to demonstrate the contrary)
- The COPY -> XML transformation is trivial -- it would be easy for clients to roll their own. At the same time, there is no standard or canonical XML representation for COPY output, and I can easily imagine different clients needing different representations. So there is limited value in providing a single, inflexible backend implementation.
- There's no need for it to be in the backend, anyway. Perhaps if there were overwhelming demand for this functionality, we would need to provide it for all client libraries and the easiest solution would be to put it in the backend, but I don't think that's the case.
If people really think XML COPY output mode is useful, why not implement it client-side first and host it on pgfoundry? If lots of people are using the client-side code, we can consider moving it into the core distribution or the backend itself at that point.
-Neil
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
