Skip site navigation (1) Skip section navigation (2)

Re: proposal casting from XML[] to int[], numeric[], text[]

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Nikolay Samokhvalov" <nikolay(at)samokhvalov(dot)com>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: proposal casting from XML[] to int[], numeric[], text[]
Date: 2007-09-28 12:46:36
Message-ID: 162867790709280546v21ff4862yedb405cda79a8b1a@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

Pavel

In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2007-09-28 13:21:16
Subject: Re: [FEATURE REQUEST] Streaming Onlinebackup(MaybeOFFTOPIC)
Previous:From: Stephen FrostDate: 2007-09-28 11:02:23
Subject: Re: Getting to 8.3 beta1

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group