Re: [HACKERS] xpath not a good replacement for xpath_string

2009-07-30 Thread James Pye
On Jul 29, 2009, at 12:12 PM, Andrew Dunstan wrote: As I said upthread, I think we can easily provide some extra convenience functions which will do what you want. The only thing I was really arguing about was the function name for such a gadget. +1. xpath_string does seem unfortunate, but

Re: [HACKERS] xpath not a good replacement for xpath_string

2009-07-29 Thread Peter Eisentraut
On Tuesday 28 July 2009 23:30:23 pg...@mohawksoft.com wrote: The thing that perplexed me was that it was not obvious from the docs how, exactly, to get the functionality that was simple and straight forward in XML2. I continue to be in favor of adding xpath_string xpath_number xpath_boolean

Re: [HACKERS] xpath not a good replacement for xpath_string

2009-07-29 Thread pgsql
On Tuesday 28 July 2009 23:30:23 pg...@mohawksoft.com wrote: The thing that perplexed me was that it was not obvious from the docs how, exactly, to get the functionality that was simple and straight forward in XML2. I continue to be in favor of adding xpath_string xpath_number

Re: [HACKERS] xpath not a good replacement for xpath_string

2009-07-29 Thread Andrew Dunstan
pg...@mohawksoft.com wrote: On Tuesday 28 July 2009 23:30:23 pg...@mohawksoft.com wrote: The thing that perplexed me was that it was not obvious from the docs how, exactly, to get the functionality that was simple and straight forward in XML2. I continue to be in favor of adding

Re: [HACKERS] xpath not a good replacement for xpath_string

2009-07-29 Thread pgsql
select datum form objects were key ='GUID' and xpath_string(datum,E'foo/bar') = 'frobozz'; The logic of the function seems is that it is intended to use extracted XML within a query. The new xpath functionality seems not to be designed to facilitate this, requiring a pretty arcane query

Re: [HACKERS] xpath not a good replacement for xpath_string

2009-07-29 Thread Andrew Dunstan
pg...@mohawksoft.com wrote: Well, the API is there, it is where, I guess, PostgreSQL is going, but I think, philosophically, the API needs to see the XML contained within SQL columns as being able to represent variable and optional columns in object oriented environments easily. The harder it

[HACKERS] xpath not a good replacement for xpath_string

2009-07-28 Thread pgsql
Sorry to bring this up, I know you've been fighting about XML for a while. Currently, I am using XML2 functionality and have tried to get the newer XPath function to work similarly, but can't quite seem to do it. I think the current xpath function is too limited. (The docs said to post problems

Re: [HACKERS] xpath not a good replacement for xpath_string

2009-07-28 Thread Mike Rylander
On Tue, Jul 28, 2009 at 3:21 PM, pg...@mohawksoft.com wrote: Sorry to bring this up, I know you've been fighting about XML for a while. Currently, I am using XML2 functionality and have tried to get the newer XPath function to work similarly, but can't quite seem to do it. I think the

Re: [HACKERS] xpath not a good replacement for xpath_string

2009-07-28 Thread Andrew Dunstan
pg...@mohawksoft.com wrote: Sorry to bring this up, I know you've been fighting about XML for a while. Currently, I am using XML2 functionality and have tried to get the newer XPath function to work similarly, but can't quite seem to do it. I think the current xpath function is too limited.

Re: [HACKERS] xpath not a good replacement for xpath_string

2009-07-28 Thread Kevin Grittner
Andrew Dunstan and...@dunslane.net wrote: This is really a usage question, which doesn't belong on -hackers. Perhaps this sentence in the 8.4.0 docs should be amended or removed?: If you find that some of the functionality of this module is not available in an adequate form with the newer

Re: [HACKERS] xpath not a good replacement for xpath_string

2009-07-28 Thread Andrew Dunstan
Kevin Grittner wrote: Andrew Dunstan and...@dunslane.net wrote: This is really a usage question, which doesn't belong on -hackers. Perhaps this sentence in the 8.4.0 docs should be amended or removed?: If you find that some of the functionality of this module is not available

Re: [HACKERS] xpath not a good replacement for xpath_string

2009-07-28 Thread Kevin Grittner
Andrew Dunstan and...@dunslane.net wrote: in fact the desired functionality is present [...] You just need to use the text() function to get the contents of the node, and an array subscript to pull it out of the result array. I just took a quick look, and that didn't jump out at me from the

Re: [HACKERS] xpath not a good replacement for xpath_string

2009-07-28 Thread pgsql
Andrew Dunstan and...@dunslane.net wrote: in fact the desired functionality is present [...] You just need to use the text() function to get the contents of the node, and an array subscript to pull it out of the result array. I just took a quick look, and that didn't jump out at me from the

Re: [HACKERS] xpath not a good replacement for xpath_string

2009-07-28 Thread Mike Rylander
On Tuesday, July 28, 2009, pg...@mohawksoft.com wrote: Andrew Dunstan and...@dunslane.net wrote: in fact the desired functionality is present [...] You just need to use the text() function to get the contents of the node, and an array subscript to pull it out of the result array. I just

Re: [HACKERS] xpath not a good replacement for xpath_string

2009-07-28 Thread Andrew Dunstan
pg...@mohawksoft.com wrote: Another thing that is troubling is that more exotic types do not seem to be supported at all. For instance, in my example I used uuid, and if one substitutes uuid() for text() that doesn't work. text() is an XPath function, with well defined semantics that