So what about XSLT?

On Fri, Aug 15, 2008 at 04:11:11PM +0300, Peter Eisentraut wrote:

An open task in replacing contrib/xml2 is the XSLT support, which
the current core implementation lacks altogether. I am known to
often be in favor of a lean core, so I have so far been hesitant to
push this further, but we should eventually come up with an
implementation for the users' sake.

So where should XSLT functionality live:

- core

+1. I've heard rumors of a PL/XSLT. Any substance to them?

- contrib
- pgfoundry

There is also a related but minor question where other interesting
XML functionality should live, such as pretty-printing and
canonicalization. These would be relatively straightward
passthroughs to functionality provided by libxml already.

Comments?

Is there some way to do a more generic (de)serialization of which one
target could be XML? CSV could be one, JSON another, and at the
moment, it appears we're taking each of these as a totally separate
project.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Peter Eisentraut <peter_e@gmx.net> writes:

An open task in replacing contrib/xml2 is the XSLT support, which the current
core implementation lacks altogether. I am known to often be in favor of a
lean core, so I have so far been hesitant to push this further, but we should
eventually come up with an implementation for the users' sake.

So where should XSLT functionality live:

That question is unanswerable except in the context of a specific
proposal for the amount of functionality and code involved. To take
it to extremes: if you are talking about adding 100 lines, no one will
object to putting it in core; if you are talking about adding 100000
lines, some of us will object. I suppose you are thinking of something
in between, but what?

regards, tom lane

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

An open task in replacing contrib/xml2 is the XSLT support, which the current
core implementation lacks altogether. I am known to often be in favor of a
lean core, so I have so far been hesitant to push this further, but we should
eventually come up with an implementation for the users' sake.

So where should XSLT functionality live:

That question is unanswerable except in the context of a specific
proposal for the amount of functionality and code involved. To take
it to extremes: if you are talking about adding 100 lines, no one will
object to putting it in core; if you are talking about adding 100000
lines, some of us will object. I suppose you are thinking of something
in between, but what?

well, contrib/xml2/xslt_proc.c has 172 lines. So I suggest we just
import that to core and drop the rest of the module as redundant.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Peter Eisentraut <peter_e@gmx.net> writes:

An open task in replacing contrib/xml2 is the XSLT support, which the current
core implementation lacks altogether.

well, contrib/xml2/xslt_proc.c has 172 lines. So I suggest we just
import that to core and drop the rest of the module as redundant.

I assume that wouldn't provide the functionality Peter wants; else the
above would have happened already in 8.3.

regards, tom lane

Am Friday, 15. August 2008 schrieb Tom Lane:

well, contrib/xml2/xslt_proc.c has 172 lines. So I suggest we just
import that to core and drop the rest of the module as redundant.

I assume that wouldn't provide the functionality Peter wants; else the
above would have happened already in 8.3.

Well, another part of my hesitation was the question whether we want to deal
with yet another library. But since libxslt has since snuck into configure
and is well-established, most of that concern goes away.