Added to TODO:
* Allow xml arrays to be cast to other data types
http://archives.postgresql.org/pgsql-hackers/2007-09/msg00981.php
http://archives.postgresql.org/pgsql-hackers/2007-10/msg00231.php
http://archives.postgresql.org/pgsql-hackers/2007-11/msg00471.php
> >
> > You're right, that's my mistake, sorry. So, having casting rules seems
> > to be the only option..
> >
>
>
> We can already cast as text[], and so we can do this:
>
> andrew=# select
> xpath('//foo/text()','12')::text[]::int[];
> xpath
> ---
> {1,2}
> (1 row)
>
>
> So why do we desper
Nikolay Samokhvalov wrote:
On Nov 12, 2007 12:59 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
I'm not clear on what you're proposing. There is no such thing as an
opclass with no operators (or at least, not a useful one), so this seems
mutually contradictory.
regards, t
On Nov 12, 2007 12:59 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I'm not clear on what you're proposing. There is no such thing as an
> opclass with no operators (or at least, not a useful one), so this seems
> mutually contradictory.
>
> regards, tom lane
>
You're right, t
"Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
> Alternative (and maybe better) approach would be:
> - create comparison functions that work in the same way as string
> comparison functions do (currently, it's straight forward since XML is
> stored as string);
> - do NOT create comparison oper
On 11/11/2007, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
>
>
> On Sep 25, 2007 10:57 AM, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> > Hello
> >
> > Current result from xpath function isn't indexable. It cannot be
> > problem with possibility cast it to some base types.
> >
> > CREATE OR REPLAC
On Sep 25, 2007 10:57 AM, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> Hello
>
> Current result from xpath function isn't indexable. It cannot be
> problem with possibility cast it to some base types.
>
> CREATE OR REPLACE FUNCTION xml_list_to_int(xml[])
> RETURNS int[] AS $$
> SELECT ARRAY(SELECT t
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Andrew Dunstan wrote:
>
>
> Peter Eisentraut wrote:
> > Am Freitag, 28. September 2007 schrieb Nikolay Samokhvalov:
Peter Eisentraut wrote:
Am Freitag, 28. September 2007 schrieb Nikolay Samokhvalov:
what should be returned for XML like "PostgreSQL
is a powerful, open source relational database system" if user
requests for text under "em" node? In XML world, the correct answer is
"PostgreSQL is a powerf
Am Freitag, 28. September 2007 schrieb Nikolay Samokhvalov:
> what should be returned for XML like "PostgreSQL
> is a powerful, open source relational database system" if user
> requests for text under "em" node? In XML world, the correct answer is
> "PostgreSQL is a powerful, open source relation
2007/9/28, Nikolay Samokhvalov <[EMAIL PROTECTED]>:
> On 9/28/07, Pavel Stehule <[EMAIL PROTECTED]> 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
>
On 9/28/07, Pavel Stehule <[EMAIL PROTECTED]> 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 d
> 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
The problem with contrib/xml2's xpath_* functions (that return
scalars) was that they are very specific. If XPath expression
evaluation returns array of values (set of XML pieces), but the
function returns only the first, significant information is lost,
while there is no any gain in speed at all.
Am Dienstag, 25. September 2007 schrieb Pavel Stehule:
> Current result from xpath function isn't indexable. It cannot be
> problem with possibility cast it to some base types.
Nikolay might be able to remind us what happened to the proposed functions
xpath_bool, xpath_text, etc.
--
Peter Eisen
Hello
Current result from xpath function isn't indexable. It cannot be
problem with possibility cast it to some base types.
CREATE OR REPLACE FUNCTION xml_list_to_int(xml[])
RETURNS int[] AS $$
SELECT ARRAY(SELECT to_number(($1[i])::text,'99.99')::int
FROM generate_series(1, a
16 matches
Mail list logo
