From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Brian Moore <brianmooreca(at)yahoo(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Allow backend to output result sets in XML |
Date: | 2004-01-21 18:19:45 |
Message-ID: | 200401211919.45651.peter_e@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Brian Moore <brianmooreca(at)yahoo(dot)com> writes:
> > i would like to begin work on the TODO item
> > Allow backend to output result sets in XML
>
> I am not sure why it's phrased that way --- surely the code to hack
> on is the client side, not the backend. Otherwise you need a
> protocol revision to make this happen, which implies hacking *both*
> ends.
>
> psql already has some code to output results as HTML tables; I'd
> think adding functionality in that vicinity would be the way to go.
Converting a libpq result set (or a JDBC result set or ...) to an XML
document should be a trivial string concatenation job that anyone can
implement in half an hour. The more interesting questions are: what
XML schema do you want to use and why? What do you want to do with the
XML in the first place? Would a streaming interface be a better? Do
you want a text document or a preparsed structure? What good would a,
say, libpq implementation be if it's more work to make a wrapper in one
of the other language bindings than implement it from scratch there?
I think "output XML" is just buzz. Give us a real use scenario and an
indication that a majority also has that use scenario (vs. the other
ones listed above), then we can talk.
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2004-01-21 19:40:12 | testing mail relays ... |
Previous Message | Tom Lane | 2004-01-21 17:23:34 | Re: SET WITHOUT OIDS and VACUUM badness? |