[BUGS] Re: BUG #7971: Xml special symbols are not unescaped when gettting value of Xml via xpath
Is there any status/progress about this bug? Looks like this bug is not very difficult to fix, but it is really annoying. -- Вилен Тамбовцев -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8237: CASE Expression - Order of expression processing
The following bug has been logged on the website: Bug reference: 8237 Logged by: Andrea Lombardoni Email address: and...@lombardoni.ch PostgreSQL version: 9.0.4 Operating system: Linux Description: I observed the following behaviour (I tested the following statements in 9.0.4, 9.0.5 and 9.3beta1): $ psql template1 template1=# SELECT CASE WHEN 0=0 THEN 0 ELSE 1/0 END; case -- 0 (1 row) template1=# SELECT CASE WHEN 1=0 THEN 0 ELSE 1/0 END; ERROR: division by zero In this case the CASE behaves as expected. But in the following expression: template1=# SELECT CASE WHEN (SELECT 0)=0 THEN 0 ELSE 1/0 END; ERROR: division by zero (Just to be sure, a SELECT (SELECT 0)=0; returns true) What I expect: template1=# SELECT CASE WHEN (SELECT 0)=0 THEN 0 ELSE 1/0 END; 0 template1=# SELECT CASE WHEN (SELECT 1)=0 THEN 0 ELSE 1/0 END; ERROR: division by zero It seems that when the CASE WHEN expression is a query, the evaluation order changes. According to the documentation, this behaviour is wrong. http://www.postgresql.org/docs/9.0/static/sql-expressions.html (4.2.13. Expression Evaluation Rules): When it is essential to force evaluation order, a CASE construct (see Section 9.16) can be used. http://www.postgresql.org/docs/9.0/static/functions-conditional.html (9.16.1. CASE): If the condition's result is true, the value of the CASE expression is the result that follows the condition, and the remainder of the CASE expression is not processed. A CASE expression does not evaluate any subexpressions that are not needed to determine the result. The discussion on postgresql-general ( http://www.postgresql.org/message-id/camq5dgq4sujpbht2-9xlapasvknul2-bb0cpyci2fp+pfsf...@mail.gmail.com ) also seems to indicate that this is a bug. At least it is a discrepancy between documentation and behaviour. -- 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 #8237: CASE Expression - Order of expression processing
On 2013-06-18 13:17:14 +, and...@lombardoni.ch wrote: template1=# SELECT CASE WHEN 1=0 THEN 0 ELSE 1/0 END; ERROR: division by zero In this case the CASE behaves as expected. But in the following expression: template1=# SELECT CASE WHEN (SELECT 0)=0 THEN 0 ELSE 1/0 END; ERROR: division by zero Hrmpf. This is rather annoying. Const simplification processes all clauses and evaluates them if it can. Which is - as demonstrated above - broken. The only reason #= SELECT CASE WHEN 1=1 THEN 0 ELSE 1/0 END; works is that we abort even looking at further WHEN clauses if we know that one WHEN succeeds. So it seems we need to stop processing after finding a single WHEN that's not const? Does anybody have a better idea? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- 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 #8237: CASE Expression - Order of expression processing
2013/6/18 Andres Freund and...@2ndquadrant.com: On 2013-06-18 13:17:14 +, and...@lombardoni.ch wrote: template1=# SELECT CASE WHEN 1=0 THEN 0 ELSE 1/0 END; ERROR: division by zero In this case the CASE behaves as expected. But in the following expression: template1=# SELECT CASE WHEN (SELECT 0)=0 THEN 0 ELSE 1/0 END; ERROR: division by zero Hrmpf. This is rather annoying. Const simplification processes all clauses and evaluates them if it can. Which is - as demonstrated above - broken. The only reason #= SELECT CASE WHEN 1=1 THEN 0 ELSE 1/0 END; works is that we abort even looking at further WHEN clauses if we know that one WHEN succeeds. So it seems we need to stop processing after finding a single WHEN that's not const? Does anybody have a better idea? probably we should to evaluate constants under subtransaction, and after exception, we should to stop precalculation of related subexpression. But it is slow :( Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8236: wal_sync_method open_datasync unavailable
The following bug has been logged on the website: Bug reference: 8236 Logged by: Ivan Email address: ak...@akifo.net PostgreSQL version: 8.4.4 Operating system: CEntOS 5.4 Description: Sync method :open_datasync daclared as supported ( http://www.postgresql.org/docs/8.4/static/runtime-config-wal.html ) But after changing this parameter I've got the following error: FATAL: invalid value for parameter wal_sync_method: open_datasync HINT: Available values: fsync, fdatasync, open_sync. -- 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 #8236: wal_sync_method open_datasync unavailable
On Tuesday, June 18, 2013 10:55 AM Ivan wrote Sync method :open_datasync daclared as supported ( http://www.postgresql.org/docs/8.4/static/runtime-config-wal.html ) But after changing this parameter I've got the following error: FATAL: invalid value for parameter wal_sync_method: open_datasync HINT: Available values: fsync, fdatasync, open_sync. The open_datasync may not supported by your system. Can you please check what are types of syncs supported in your system. Use the pg_test_fsync tool which is present in contrib folder. Regards, Hari babu. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8238: duplicate of bug #6372 on panffs
The following bug has been logged on the website: Bug reference: 8238 Logged by: Jim Hughes Email address: james.e.hug...@boeing.com PostgreSQL version: 9.1.4 Operating system: SLES 11 Description: Upon creating a database on a panfs (Panasas proprietary fs) directory I get: createdb: database creation failed: ERROR: could not fsync file base/16387: Invalid argument This is a duplicate of bug #6372 and is fixed by applying the patch for copydir.c listed in the thread. So we confirm this problem also exists on another fs in addition to CIFS. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8239: postgresql cannot run after install with apt-get because of permisions
The following bug has been logged on the website: Bug reference: 8239 Logged by: Niflheim123 Email address: niflheim...@gmail.com PostgreSQL version: 9.1.0 Operating system: Kali Linux ARM Chroot Android Description: If I run apt-get install postgresql in an chroot enviroment on my android phone I get on start that it cannot bind to socket. Found out this today: the user postgres needs permisions to run on android so it can bind to sockets. Add to install script please: if the installer detects that it is an ARM (or also detects Kali linux) architecture and its on Android: usermod -a -G aid_inet postgres Then start the server. Thank you. -- 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 #8237: CASE Expression - Order of expression processing
Andres Freund and...@2ndquadrant.com writes: On 2013-06-18 13:17:14 +, and...@lombardoni.ch wrote: template1=# SELECT CASE WHEN (SELECT 0)=0 THEN 0 ELSE 1/0 END; ERROR: division by zero Hrmpf. This is rather annoying. Annoying, maybe. Bug, no. The manual is pretty clear that you don't have a lot of control over order of evaluation of subexpressions. So it seems we need to stop processing after finding a single WHEN that's not const? That's not an acceptable fix. 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
