Initial review of xslt with no limits patch
in [PgSql]
|
Prev: english parser in text search: support for multiplewords in the same position
Next: [HACKERS] Postgres as Historian
From: Pavel Stehule on 6 Aug 2010 02:29 2010/8/6 David Fetter <david(a)fetter.org>: > On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote: >> 2010/8/6 Andrew Dunstan <andrew(a)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 Regards Pavel > > Cheers, > David. > -- > David Fetter <david(a)fetter.org> http://fetter.org/ > Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter > Skype: davidfetter XMPP: david.fetter(a)gmail.com > iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics > > Remember to vote! > Consider donating to Postgres: http://www.postgresql.org/about/donate > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: David Fetter on 6 Aug 2010 02:18 On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote: > 2010/8/6 Andrew Dunstan <andrew(a)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. :) Cheers, David. -- David Fetter <david(a)fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter(a)gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Mike Fowler on 6 Aug 2010 10:12 On 06/08/10 15:08, Andrew Dunstan wrote: > > > On 08/06/2010 02:29 AM, Pavel Stehule wrote: >> 2010/8/6 David Fetter<david(a)fetter.org>: >>> On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote: >>>> 2010/8/6 Andrew Dunstan<andrew(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 6 Aug 2010 10:08
On 08/06/2010 02:29 AM, Pavel Stehule wrote: > 2010/8/6 David Fetter<david(a)fetter.org>: >> On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote: >>> 2010/8/6 Andrew Dunstan<andrew(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |