On 9/28/07, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> > 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
Will it be convenient for cases when there are many different (various
structures) XMLs in one column (no single DTD)?
>
> > - 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.
Actually, casting to numeric types might seem to be odd. But there is
some sense from practical point of view -- it works and that's better
that nothing (like now). But it's too late for 8.3, isn't it?
>
> > 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]
I do not understand. Do you mean that there is no equality comparison
operator for type xml yet?
To implement GIN for xml[] we need to have comparison operator for
xml. Standard says "XML values are not comparable" (subclause 4.2.4 of
the latest draft from wiscorp.com), but without that cannot implement
straight GIN support, what is not good :-/
--
Best regards,
Nikolay