The problem with contrib/xml2's xpath_* functions (that return
scalars) was that they are very specific. If XPath expression
evaluation returns array of values (set of XML pieces), but the
function returns only the first, significant information is lost,
while there is no any gain in speed at all.
The key idea was to create only one generic function at the first
stage -- xpath(), returning an array of XML pieces.
We would create wrappers returning int[], bool[], string[], but there
are several issues with such functions: - if the type of the data located on nodes that match XPath
expression differs from what is expected, what should we do? - in XML world, if you request for a text under some node,
all
descendants should be involved in generating result string (example:
what should be returned for XML like "<em><strong>PostgreSQL</strong>
is a powerful, open source relational database system</em>" if user
requests for text under "em" node? In XML world, the correct answer is
"PostgreSQL is a powerful, open source relational database system" --
concatenation of all strings from the node itself and all its
descendants, in the correct order. Will be this expected for RDBMS
users?).
Regarding GIN indexes, alternative approach would be creating opclass
for xml[], it should be pretty simple (and better than creating
implicit CASTs for xml[]<->int[], xml[]<->bool[], etc). Can we do this
for 8.3 or it's too late? It would be very helpful feature.
Without that, the only way to have indexes is to use functional btree
indexes over XPath expression (smth like "...btree(((xpath('...',
field)[1]::text))" -- pretty ugly construction...)
On 9/25/07, Peter Eisentraut <peter_e@gmx.net> wrote:
> Am Dienstag, 25. September 2007 schrieb Pavel Stehule:
> > Current result from xpath function isn't indexable. It cannot be
> > problem with possibility cast it to some base types.
>
> Nikolay might be able to remind us what happened to the proposed functions
> xpath_bool, xpath_text, etc.
>
> --
> Peter Eisentraut
> http://developer.postgresql.org/~petere/
>
--
Best regards,
Nikolay