Re: patches for items from TODO list

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073