> 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?
raise exception
> - 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?).
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
currently:
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)[1]::text))" -- pretty ugly construction...)
It's not usefull, if xpath returns more values
Regards
Pavel Stehule
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
