On 06/08/10 15:08, Andrew Dunstan wrote:
On 08/06/2010 02:29 AM, Pavel Stehule wrote:
2010/8/6 David Fetter<da...@fetter.org>:
On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote:
2010/8/6 Andrew Dunstan<and...@dunslane.net>:
On 08/05/2010 06:56 PM, Mike Fowler wrote:
SELECT
xslt_process('<employee><name>cim</name><age>30</age><pay>400</pay></employee>'::text,
$$<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
version="1.0">
<xsl:output method="xml" omit-xml-declaration="yes" indent="yes"/>
[snip]
</xsl:stylesheet>$$::text, 'n1=v1,n2=v2,n3=v3,n4=v4,n5=v5'::text)
I haven't been paying attention to this, so sorry if this has been
discussed
before, but it just caught my eye. Why are we passing these params
as a
comma-separated list rather than as an array or as a variadic list of
params? This looks rather ugly. What if you want to have a param that
includes a comma?
There is probably problem in pairs - label = value. Can be nice, if we
can use a variadic functions for this, but I am afraid, ...
using a variadic function isn't too much nice now
some xslt_process(xmlsrc, 'n1=v1','n2=v2','n3=v3'
This sounds like the perfect case for pulling hstore into core code. :)
I afraid so integration of hstore can break and block work on real
hash support. I would to have hash tables in core, but with usual
features and usual syntax - like Perl or PHP
Can we just keep this discussion within reasonable bounds? The issue
is not hstore or other hashes, but how to do the param list for xslt
sanely given what we have now. A variadic list will be much nicer than
what is currently proposed.
cheers
andrew
+1
Variadic seems the most sensible to me anyways.
However the more urgent problem is, pending someone spotting an error in
my ways, neither the existing code or the patched code appear able to
evaluate the parameters. Note than in my example I supplied a default
value for the fifth parameter and not even that value is appearing in
the outputted XML.
Regards,
--
Mike Fowler
Registered Linux user: 379787
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
