Re: [HACKERS] So what about XSLT?
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] So what about XSLT?
Andrew Dunstan <[EMAIL PROTECTED]> writes: >> Peter Eisentraut <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] So what about XSLT?
Tom Lane wrote: Peter Eisentraut <[EMAIL PROTECTED]> 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 10 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] So what about XSLT?
Peter Eisentraut <[EMAIL PROTECTED]> 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 10 lines, some of us will object. I suppose you are thinking of something in between, but what? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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 <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] So what about XSLT?
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 - 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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers