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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Nikolay Samokhvalov <nikolay(at)samokhvalov(dot)com>, pgsql-hackers(at)postgresql(dot)org, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Subject: Re: proposal casting from XML[] to int[], numeric[], text[]
Date: 2007-11-03 22:20:25
Message-ID: 200711032220.lA3MKPR15985@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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:
> >
> >> 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?).
> >>
> >
> > Well, if that is the defined behavior for XPath, then that's what we should
> > do.
> >
> >
>
> The xpath string value of a single node is the concatentation of the
> text children of the node and all its children in document order, IIRC.
> But that's not what we're dealing with here. xpath() doesn't return a
> single node but a node set (or so say the docs). The string value of a
> node set is in effect the string value of its first member, which seems
> less than useful in this context, or at least no great guide for us.
>
> I think there's probably a good case for a cast from xml[] to text[] if
> we don't have one.
>
> cheers
>
> andrew
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-11-03 22:39:04 Re: building 8.3beta2 w/ 'make check' consumes A LOT of disk space
Previous Message Tom Lane 2007-11-03 22:15:57 Re: CREATE CONSTRAINT TRIGGER compatibility issue