Duplicate versions of functions (e.g., there would be XMLPATH() as the main
XPath function for XML type, producing arrays of values of XML type in
general case -- non-standard, but generalized).

In addition to two SQL files for registration of module functions in
database, I would move XSLT functions to separate SQL file (many people do
not need XSLT, just XPath, or vice versa). Also, maybe it's worth to adjust
Makefile to make using of contrib/xml2 without XSLT (on systems w/o libxslt)
a little bit simpler (now everyone have to edit both Makefile and ...sql.in

On 1/11/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:

Assuming a working xml type, what do you think the future of the
contrib/xml2 module should be?

At the moment, I'd imagine that we add duplicate versions of most
functions, where appropriate, that use the xml type instead of the text
type.  Perhaps we should supply two sets of SQL files, so that users
have the choice of using the "legacy" versions or the "type-safe"
versions.  Anything else?

(I understand that some people are researching GIN-optimized XPath
access to XML data, but that is really a bit further out.)

Peter Eisentraut

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Best regards,

Reply via email to