> 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
It is corect. Or we can disallow any nested elements in casting array.
It's poblem only for text type. Numeric types are clear.
> 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.
It's not practic. If I would to use it for functional indexes for
xpath functions I need constructor for xml, and I have not it
xpath('/root/id/text()', column)::int @< ARRAY[199,2200,222]
> Without that, the only way to have indexes is to use functional btree
> indexes over XPath expression (smth like "...btree(((xpath('...',
> field)::text))" -- pretty ugly construction...)
It's not usefull, if xpath returns more values
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?