[BUGS] BUG #4206: function xpath gives wrong results
The following bug has been logged online:
Bug reference: 4206
Logged by: Martin Drescher
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Windows XP SP2
Description:function xpath gives wrong results
Details:
To demonstrate I use the following simple XML.
?xml version=1.0?
elem1
elem2one/elem2
elem2two/elem2
elem2three/elem2
elem3 att=2/
/elem1
I executed the following query in psql (with the corresponding XPath).
select xpath('//text()',xmlparse(document '?xml version=1.0
?elem1elem2one/elem2elem2two/elem2elem2three/elem2elem3
att=2//elem1'));
The expected result is checked using Altova XMLSpy 2008.
XPath: (//text())[1]
Expected result: {one}
Actual Result:
ERROR: XX000: invalid XPath expression
DETAIL: Invalid expression
CONTEXT: SQL function xpath statement 1
LOCATION: xml_ereport, .\src\backend\utils\adt\xml.c:1351
XPath: boolean(/elem1)
Expected result: {true}
Actual Result:
ERROR: XX000: invalid XPath expression
DETAIL: Invalid expression
CONTEXT: SQL function xpath statement 1
LOCATION: xml_ereport, .\src\backend\utils\adt\xml.c:1351
XPath: /elem1/..
Expected result: document root
Actual Result:
{x
elem1
elem2one/elem2
elem2two/elem2
elem2three/elem2
elem3 att=\2\/
/elem1
/x}
Note: This XPath returns the document root. I donât know, how you choose
to represent it. However, it should not return the element x
The problem imo is in .\src\backend\utils\adt\xml.c:3294, where a
x-element is wrapped around the xml and the XPath-expression is prepended
by /x.
This is not needed for XML documents and fragments consisting of a single
root. Instead it breaks many XPath-Expressions; like where you use multiple
absolute path expressions or function calls.
I think, queries on a fragment consisting of multiple roots are not possible
with XPath 1.0.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4186: set lc_messages does not work
Thomas H. [EMAIL PROTECTED] writes: nevertheless the problem/bug exists: changing LC_MESSAGES has no effect on the windows boxes, while it works on the non-win32 systems. all i really would like is to get english system messages back on our non-english win32 servers - like they were pre 8.3.1. So far as I can tell, the backend's handling of LC_MESSAGES hasn't changed at all between 8.1.2 and 8.3.1, so if it used to work for you then there's been some other relevant change. Any idea what? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4200: Regexp character classes not UTF8-compliant
I am not sure how to help you except to say that UTF8 is a character set
encoding, while en_US.UTF-8 is more of an encoding with a locale. My
guess is that if you use *.UTF-8 where you specified the proper
localization language, it would work.
http://www.postgresql.org/docs/8.2/static/locale.html
---
Jean-Baptiste Quenot wrote:
The following bug has been logged online:
Bug reference: 4200
Logged by: Jean-Baptiste Quenot
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Linux Ubuntu Hardy
Description:Regexp character classes not UTF8-compliant
Details:
PostgreSQL documentation at
http://www.postgresql.org/docs/8.3/static/functions-matching.html describes
the various character classes, and they can be used to match or replace
strings with regexp support. However, the [:alnum:] and [:alpha:] character
classes are not UTF8-compliant, like shown in the examples below:
dockee=# show client_encoding;
client_encoding
-
UTF8
(1 row)
dockee=# show lc_ctype;
lc_ctype
-
en_US.UTF-8
(1 row)
dockee=# select regexp_replace('b??bu', '[[:alnum:]]', '', 'g');
regexp_replace
??
(1 row)
ovhdev=# select regexp_replace('b??bu', '[[:alpha:]]', '', 'g');
regexp_replace
??
(1 row)
dockee=# select regexp_replace('b??bu', $$\w$$, '', 'g');
regexp_replace
??
(1 row)
Only characters in the ASCII range were correctly detected to belong to the
[:alnum:] character class, whereas other characters are valid too.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4186: set lc_messages does not work
From: Tom Lane [EMAIL PROTECTED] Thomas H. [EMAIL PROTECTED] writes: nevertheless the problem/bug exists: changing LC_MESSAGES has no effect on the windows boxes, while it works on the non-win32 systems. all i really would like is to get english system messages back on our non-english win32 servers - like they were pre 8.3.1. So far as I can tell, the backend's handling of LC_MESSAGES hasn't changed at all between 8.1.2 and 8.3.1, so if it used to work for you then there's been some other relevant change. Any idea what? well... i'm not saying it worked in earlier versions. but prior to 8.3.1 (i've tested 8.3.0 and 8.2.3), the error messages were in english no matter what the config file or the os locale says. now, with 8.3.1, error system messages are always in the os' locale, and thus the bugreport. there is currently no way to set the pg system messages' language, as the LC_MESSAGES setting seems to be defunct on win32 systems. as a small proof, i installed the win32 8.3.0 from postgresql.org as a fresh install and changed the postgresl.conf' lc_messages value to 'English_UnitedStates'. here's the psql output: 8.3.0: --- postgres=# show lc_messages; lc_messages English_UnitedStates (1 row) postgres=# select x; ERROR: column x does not exist LINE 1: select x; ^ postgres=# set lc_messages='French'; SET postgres=# select x; ERROR: column x does not exist LINE 1: select x; ^ postgres=# --- -- all system messages are in english. after *upgrading* to 8.3.1 (again, using the official binaries), the output looks like this: 8.3.1: --- postgres=# show lc_messages; lc_messages -- English_UnitedStates (1 Zeile) postgres=# select x; FEHLER: Spalte »x« existiert nicht ZEILE 1: select x; ^ postgres=# set lc_messages='French'; SET postgres=# select x; FEHLER: Spalte »x« existiert nicht ZEILE 1: select x; ^ postgres=# show lc_messages; lc_messages - French (1 Zeile) postgres=# --- -- all system messages are in german (the os' locale) so clearly between 8.3.0 and 8.3.1, something must have changed. but the only patch that concerned win32 msvc/locale is the one you said wasn't even included... what i noticed: if i delete the folder share/locale/de/ the system messages are back to english - but that can't be THE solution, can it? :) regards, thomas -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4186: set lc_messages does not work
From: Thomas H. [EMAIL PROTECTED] what i noticed: if i delete the folder share/locale/de/ the system messages are back to english - but that can't be THE solution, can it? :) well, it actually was the solution, at least to the weird part of the problem: there are two versions of win32 binaries available on postgres.org. there's the installer msi version, and there is the installerless zip version. the installer version does NOT install the folder share/locale/! so when using the msi installer, postgres has no translations at all - thus the fallback to english. the zipped version contains the share/locale/ folder. for installing 8.3.0, i've been using the msi installer version. for upgrading to 8.3.1, i've been unpacking the files from zip version into the postgresql directory... i've just verified that the 8.3.1 msi version provided on postgres.org also does NOT contain the locale folder files. should i report this as a separate bug/problem? so at least that explains the changed behaviour. nevertheless, LC_MESSAGES seems to be defunct - with the locale folder present, pg always picks the os' language and ignores the lc_message value. - thomas -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
