2007/9/28, Nikolay Samokhvalov <nikolay(at)samokhvalov(dot)com>:
> On 9/28/07, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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)?
I don't know
> > > - 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?
I thing so SQL based casting like my cust functions are relative
simple for adding to core now.
> > > 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?
No, I mean some different. Nobody will construct special xml nodes for
quality comparision with xpath function when expect xpath's result as
int, or float. So when result of xpath is xml but is with possible
casting to int it's more simple do casting and build index on int
because I can search int.
> 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 :-/
I belive so xml values are not comparable, but I belive so the are
transferable to some of base types.
In response to
pgsql-hackers by date
|Next:||From: Alvaro Herrera||Date: 2007-09-28 13:21:16|
|Subject: Re: [FEATURE REQUEST] Streaming Onlinebackup(MaybeOFFTOPIC)|
|Previous:||From: Stephen Frost||Date: 2007-09-28 11:02:23|
|Subject: Re: Getting to 8.3 beta1|