Re: xpath not a good replacement for xpath_string
От | Mike Rylander |
---|---|
Тема | Re: xpath not a good replacement for xpath_string |
Дата | |
Msg-id | b918cf3d0907281620h6fc6d068uc036fbc2b6488fa5@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: xpath not a good replacement for xpath_string (pgsql@mohawksoft.com) |
Список | pgsql-hackers |
On Tuesday, July 28, 2009, <pgsql@mohawksoft.com> wrote: >> Andrew Dunstan <andrew@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 >> documentation. Perhaps there should be an example or two of how to >> get the equivalent functionality through the newer standard API, for >> those looking to migrate? >> >> Would it make sense to supply convenience SQL functions which map >> some of the old API to the new? > > 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. > > 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 used to extract the text content of a node, in this case the uuid element. > The API is less intuitive than the previous incarnation and is, indeed, > more difficult to use. It may be easier to use for those not familiar with more advanced XPath, but it also has non-standard default actions. That being said, I'd love to see wrapper functions that provide the older api but leverage the core code. --miker -- Mike Rylander| VP, Research and Design| Equinox Software, Inc. / The Evergreen Experts| phone: 1-877-OPEN-ILS (673-6457)|email: miker@esilibrary.com| web: http://www.esilibrary.com
В списке pgsql-hackers по дате отправления: