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, bu

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

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 ar

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
> 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_n

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-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 tha

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

2009-07-28 Thread Mike Rylander
On Tuesday, July 28, 2009, wrote: >> Andrew Dunstan 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 th

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

2009-07-28 Thread pgsql
> Andrew Dunstan 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 > documen

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

2009-07-28 Thread Kevin Grittner
Andrew Dunstan 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 documentation.

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

2009-07-28 Thread Andrew Dunstan
Kevin Grittner wrote: Andrew Dunstan 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

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

2009-07-28 Thread Kevin Grittner
Andrew Dunstan 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 API, please explain

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 Mike Rylander
On Tue, Jul 28, 2009 at 3:21 PM, 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 functio

[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 t