Neil Conway wrote:
> Bruce Momjian wrote:
> > 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.
All I can say is that we rejected an XML in the client patch a long time
ago and the discussion was that it belongs in the backend so everyone
can use it. I don't use XML myself so I have no opinion. We need
people who need XML output to comment in this thread.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
