Re: [BUGS] setseed accepts bad seeds
On Mon, 10 Mar 2008, Tom Lane wrote:
I'd be inclined to leave the mapping alone and just insert a warning
(or hard error) for inputs outside the range -1 to 1.
Here's a patch that errors out for out of range values.
Kris JurkaIndex: doc/src/sgml/func.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/func.sgml,v
retrieving revision 1.423
diff -c -r1.423 func.sgml
*** doc/src/sgml/func.sgml 6 Mar 2008 18:49:32 - 1.423
--- doc/src/sgml/func.sgml 10 Mar 2008 06:11:55 -
***
*** 828,834
row
entryliteralfunctionsetseed/function(typedp/type)/literal/entry
entrytypevoid/type/entry
!entryset seed for subsequent literalrandom()/literal calls
(value between 0 and 1.0)/entry
entryliteralsetseed(0.54823)/literal/entry
entry/entry
/row
--- 828,834
row
entryliteralfunctionsetseed/function(typedp/type)/literal/entry
entrytypevoid/type/entry
!entryset seed for subsequent literalrandom()/literal calls
(value between -1.0 and 1.0)/entry
entryliteralsetseed(0.54823)/literal/entry
entry/entry
/row
Index: src/backend/utils/adt/float.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/float.c,v
retrieving revision 1.153
diff -c -r1.153 float.c
*** src/backend/utils/adt/float.c 1 Jan 2008 19:45:52 - 1.153
--- src/backend/utils/adt/float.c 10 Mar 2008 06:11:55 -
***
*** 1684,1691
setseed(PG_FUNCTION_ARGS)
{
float8 seed = PG_GETARG_FLOAT8(0);
! int iseed = (int) (seed * MAX_RANDOM_VALUE);
srandom((unsigned int) iseed);
PG_RETURN_VOID();
--- 1684,1695
setseed(PG_FUNCTION_ARGS)
{
float8 seed = PG_GETARG_FLOAT8(0);
! int iseed;
+ if (seed -1 || seed 1)
+ elog(ERROR, setseed parameter %f out of range [-1,1], seed);
+
+ iseed = (int) (seed * MAX_RANDOM_VALUE);
srandom((unsigned int) iseed);
PG_RETURN_VOID();
Index: src/backend/utils/misc/guc.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.435
diff -c -r1.435 guc.c
*** src/backend/utils/misc/guc.c10 Mar 2008 03:22:29 - 1.435
--- src/backend/utils/misc/guc.c10 Mar 2008 06:11:55 -
***
*** 1849,1855
GUC_NO_SHOW_ALL | GUC_NO_RESET_ALL | GUC_NOT_IN_SAMPLE
| GUC_DISALLOW_IN_FILE
},
phony_random_seed,
! 0.5, 0.0, 1.0, assign_random_seed, show_random_seed
},
{
--- 1849,1855
GUC_NO_SHOW_ALL | GUC_NO_RESET_ALL | GUC_NOT_IN_SAMPLE
| GUC_DISALLOW_IN_FILE
},
phony_random_seed,
! 0.5, -1.0, 1.0, assign_random_seed, show_random_seed
},
{
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Help needed in Solving the problem in pg_restore
Respected sir, I am new Postgres Sql and I am using this database with Java Technology. I am executing the below statements in command prompt and they are executing fine but when I am executing it through my java program it is also working fine but it is not coming. It is continuously executing the statement because of this problem I have to stop the server every time when I am executing the restore statement. Database is restored properly through java program but it is not coming out properly. C:\Program Files\PostgreSQL\8.2\binpg_restore.exe -i -h localhost -p 5432 -d sdf C:\Program Files\PostgreSQL\8.2\bin\.backup -- Command prompt. pg_restore.exe -i -h localhost -p 5432 -d +d+ -v +\+c+\ -Java program psql.exe -h localhost -p 5432 -d +d+ -f +\+c+\ -Java program Please help me out in solving the problem. Regards, Mohit Uppal HYPERLINK BLOCKED::mailto:[EMAIL PROTECTED][EMAIL PROTECTED] Software Engineer Office (( (+91) 11204043400 (Ext 233) Cell (( (+91) 987243 No virus found in this outgoing message. Checked by AVG. Version: 7.5.518 / Virus Database: 269.21.7 - Release Date: 3/8/2008 12:00 AM
Re: [BUGS] setseed accepts bad seeds
Kris Jurka [EMAIL PROTECTED] writes: On Mon, 10 Mar 2008, Tom Lane wrote: I'd be inclined to leave the mapping alone and just insert a warning (or hard error) for inputs outside the range -1 to 1. Here's a patch that errors out for out of range values. Applied, thanks. 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
[BUGS] BUG #4022: DST Time Zone Bug related to: select now() at time zone 'EST'
The following bug has been logged online: Bug reference: 4022 Logged by: Username_PalmTreesNSand Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 Operating system: Windows Vista Description:DST Time Zone Bug related to: select now() at time zone 'EST' Details: I have recently noticed a problem since the Daylight savings time change (past 1-2 days). The following query returns the time from an hour ago (I'm in EST, but I need to be able to handle other time zones): select now() at time zone 'EST' or select now() at time zone 'CST' This query returns the correct time for EST: select now() -- 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] [PATCH] Don't bail with legitimate -N/-B options
FYI, the restriction that -B must be larger than -N will be removed in 8.4. --- Andreas Kling wrote: Greetings, Starting PostgreSQL 8.3.0 with the default options used by Gentoo Linux (-N 40 -B 80) causes it to bail with an error message. the number of buffers (-B) must be at least twice the number of allowed connections (-N) and at least 16 The problem is that NBuffers is actually max autovacuum connections + NBuffers. My attached patch fixes this by adding max autovacuum connections * 2 to NBuffers before the check. Best regards, Andreas Kling ACG Nystr?m AB ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.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 #4022: DST Time Zone Bug related to: select now() at time zone 'EST'
Username_PalmTreesNSand [EMAIL PROTECTED] writes: I have recently noticed a problem since the Daylight savings time change (past 1-2 days). The following query returns the time from an hour ago (I'm in EST, but I need to be able to handle other time zones): select now() at time zone 'EST' orselect now() at time zone 'CST' This query returns the correct time for EST: select now() I see no bug here. We're in daylight saving time now, so the zone is EDT not EST. IOW, if it's currently 10:10 EDT, it is also a true statement that it's 9:10 EST. 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 #4020: RFE: have way to log autovacuum activity
Joseph S wrote: Alvaro Herrera wrote: Yeah, we have a configurable autovacuum log on 8.3. Sorry, I looked but didn't see it. #log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and # their durations, 0 logs only # actions running at least that time. We don't log start of action though ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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 #4020: RFE: have way to log autovacuum activity
Alvaro Herrera wrote: Yeah, we have a configurable autovacuum log on 8.3. Sorry, I looked but didn't see it. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Rulese Bug: Instead of reporting incorrect insert count.
According to the documentation at Rules and Command Status http://www.postgresql.org/docs/8.2/static/rules-status.html when creating rules, the resulting command status from the rules executed is dependent upon the rules that were added. According to the documentation: If there is any unconditional INSTEAD rule for the query, then the original query will not be executed at all. In this case, the server will return the command status for the last query that was inserted by an INSTEAD rule (conditional or unconditional) and is of the same command type (INSERT, UPDATE, or DELETE) as the original query. If no query meeting those requirements is added by any rule, then the returned command status shows the original query type and zeroes for the row-count and OID fields. My understanding (and that of at least several others) indicates that only those conditional rules that are true should be added to the query plan. So if there are 3 rules, and 2 of them are false and only one is true, then the rule that met the WHERE criteria should be the only one added to the query plan. In the case described in the documentation, if there are one or more unconditional rules, then the result of the query will be the result of the last rule that was added to the query plan. Therefore if there is an unconditional rule, and several conditional rules, of which only one of those whose where clause is true, then the result of the query should be that of the single conditional query that should have been executed (taking into account that it must be alphabetically after the unconditional rule). The behavior I am seeing is not following this type of activity, consider the following case: test=# create table foo (x integer); CREATE TABLE test=# create table foo1 (x integer); CREATE TABLE test=# create table foo2 (x integer); CREATE TABLE test=# create rule foo_0 as on insert to foo do instead nothing; CREATE RULE test=# create rule foo_1 as on insert to foo where NEW.x = 1 do instead insert into foo1 (x) values (NEW.x); CREATE RULE test=# create rule foo_2 as on insert to foo where NEW.x = 2 do instead insert into foo2 (x) values (NEW.x); CREATE RULE test=# insert into foo (x) values (0); INSERT 0 0 test=# insert into foo (x) values (1); INSERT 0 0 test=# insert into foo (x) values (2); INSERT 0 1 test=# insert into foo (x) values (3); INSERT 0 0 The line highlighted in red (annotated with ) indicates a return of INSERT 0 0 where it should have returned INSERT 0 1 due to the fact that only one rule should have been added to the query plan. However, the rule foo_2 was added to the query plan and inserted no rows and therefore the result was insert 0 0. Refer to this postgresql forums thread http://www.postgresqlforums.com/forums/viewtopic.php?f=42t=606 for more discussion on this topic. Shawn Chasse ExaGrid Systems, Inc. 2000 West Park Drive Westborough, MA 01581 Office: 508-898-2872 Ext 332 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] www.exagrid.com http://www.exagrid.com/
Re: [BUGS] Rulese Bug: Instead of reporting incorrect insert count.
Shawn Chasse [EMAIL PROTECTED] writes: According to the documentation: If there is any unconditional INSTEAD rule for the query, then the original query will not be executed at all. In this case, the server will return the command status for the last query that was inserted by an INSTEAD rule (conditional or unconditional) and is of the same command type (INSERT, UPDATE, or DELETE) as the original query. If no query meeting those requirements is added by any rule, then the returned command status shows the original query type and zeroes for the row-count and OID fields. My understanding (and that of at least several others) indicates that only those conditional rules that are true should be added to the query plan. So if there are 3 rules, and 2 of them are false and only one is true, then the rule that met the WHERE criteria should be the only one added to the query plan. This is mere wishful thinking, I'm afraid. You're supposing that the WHERE clause is evaluated to decide whether to insert the rule query into the plan, which is not the case --- it could not work in any situation where the WHERE clause depends on runtime data. All rules applicable to the query type are inserted in the plan, and their WHERE clauses are applied at query runtime; as indeed is described in the manual. 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
[BUGS] BUG #4023: The transaction control does not work for sequences
The following bug has been logged online:
Bug reference: 4023
Logged by: Giovani Murilo Dantas Correa
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.0 and 8.1.9
Operating system: Linux 2.6.X (Slackware and Fedora)
Description:The transaction control does not work for sequences
Details:
create sequence seq_test;
select nextval('seq_test'); --return value 1
select nextval('seq_test'); --return value 2
select nextval('seq_test'); --return value 3
BEGIN;
select nextval('seq_test'); --return value 4
select nextval('seq_test'); --return value 5
select nextval('seq_test'); --return value 6
ROLLBACK;
select currval('seq_test'); --return value 6
This is not right. The currval must have be 3 and not 6.
--
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 #4023: The transaction control does not work for sequences
Giovani Murilo Dantas Correa [EMAIL PROTECTED] writes: Description:The transaction control does not work for sequences This is not a bug. It is an intentional and very clearly documented behavior. 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] LISTEN/NOTIFY race condition?
Hello,
I've figured out the LISTEN / NOTIFY race condition I had previously
encountered. It is not trivial, so I'll try to give as much details as
possible to describe what is going on.
Here is a description of the two Postgres functions involved in the race
condition:
void CommitTransaction()
{
...
/* NOTIFY commit must come before lower-level cleanup */
AtCommit_Notify();
...
/*
* Here is where we really truly commit.
*/
latestXid = RecordTransactionCommit();
...
/*
* This is all post-commit cleanup. Note that if an error is raised here,
* it's too late to abort the transaction. This should be just
* noncritical resource releasing.
*
* The ordering of operations is not entirely random. The idea is:
* release resources visible to other backends (eg, files, buffer pins);
* then release locks; then release backend-local resources. We want to
* release locks at the point where any backend waiting for us will see
* our transaction as being fully cleaned up.
*
* Resources that can be associated with individual queries are handled by
* the ResourceOwner mechanism. The other calls here are for backend-wide
* state.
*/
ResourceOwnerRelease(TopTransactionResourceOwner,
RESOURCE_RELEASE_LOCKS,
true, true);
...
}
void Async_Listen(const char *relname)
{
...
lRel = heap_open(ListenerRelationId, ExclusiveLock);
...
/*
* OK to insert a new tuple
*/
simple_heap_insert(lRel, tuple);
...
heap_close(lRel, ExclusiveLock);
...
}
In summary, CommitTransaction() notifies FIRST and commits AFTER.
Async_Listen() releases its lock BEFORE the end of its transaction.
I've written a program that triggers the bug quickly. Here is what this
program do:
1) The program deletes every row of the table 'the_log'. This table
contains an AFTER-INSERT trigger that notifies processes listening on
it.
2) The program starts a command thread and an event thread concurrently.
3) The command thread executes the following statements:
a) BEGIN TRANSACTION
b) INSERT INTO the_log ...
c) COMMIT
4) The event thread executes 'LISTEN the_log'.
5) The event thread executes 'SELECT * FROM the_log'.
6) If the event thread found the event, we clean up and go back to 1).
7) The event thread waits for a notification. If the notification is
received, we clean up and go back to 1).
8) We reproduced the bug.
I've instrumented the Postgres source to show what is going on in the
functions of interest. I print both the executing process PID and the
current time in microseconds. My machine has only one CPU. Hence, I'm
pretty sure the following trace accurately reflects what is happening
when my program is executing.
Note:
PID 29295 is the backend for the command thread.
PID 29296 is the backend for the event thread.
Blank lines correspond to context switches.
Command thread: executing |start transaction|.
Event thread: executing |LISTEN the_log|.
// The command backend is handling 'start transaction'.
DEBUG: [PID 29295] [Time 497310]:
BeginTransactionBlock() called for BEGIN
Command thread: executing |insert into the_log...|.
// The event backend is doing the listen.
DEBUG: [PID 29296] [Time 499744]: StartTransaction() called
DEBUG: Async_Listen(the_log,29296)
DEBUG: [PID 29296] [Time 501046]: CommitTransaction() called
DEBUG: [PID 29296] [Time 501163]: RecordTransactionCommit() called
// The command backend is handling 'insert'.
DEBUG: Async_Notify(the_log)
DEBUG: [PID 29295] [Time 502624]:
CommitTransactionCommand: incrementing command counter
Command thread: executing |commit|.
// The command backend is handling 'commit'.
DEBUG: [PID 29295] [Time 503192]: CommitTransaction() called
DEBUG: [PID 29295] AtCommit_Notify
DEBUG: [PID 29295] AtCommit_Notify: done
DEBUG: [PID 29295] [Time 507981]: RecordTransactionCommit() called
// The event backend is still handling 'listen'.
DEBUG: [PID 29296] [Time 508319]:
CommitTransaction: about to release with RESOURCE_RELEASE_LOCKS.
Event thread: executing |select * from the_log|.
// The event backend is handling 'select'.
DEBUG: [PID 29296] [Time 508754]: StartTransaction() called
DEBUG: [PID 29296] [Time 510082]: CommitTransaction() called
DEBUG: [PID 29296] [Time 510207]: RecordTransactionCommit() called
DEBUG: [PID 29296] [Time 510326]:
CommitTransaction: about to release with RESOURCE_RELEASE_LOCKS.
// The command thread is still handling 'commit'.
DEBUG: [PID 29295] [Time 510690]:
CommitTransaction: about to release with RESOURCE_RELEASE_LOCKS.
Analysis:
The command backend begins a transaction, then the event backend begins a
transaction for LISTEN. The event backend updates the pg_listener table
in mutual exclusion, but it releases the mutex before the transaction is
commited. The command thread does its INSERT then starts its COMMIT. The
command backend scans the pg_listener table and doesn't find
Re: [BUGS] LISTEN/NOTIFY race condition?
Laurent Birtz [EMAIL PROTECTED] writes: The command backend begins a transaction, then the event backend begins a transaction for LISTEN. The event backend updates the pg_listener table in mutual exclusion, but it releases the mutex before the transaction is commited. The command thread does its INSERT then starts its COMMIT. The command backend scans the pg_listener table and doesn't find anyone to notify. Before the command backend has the time to actually commit, the event backend commits and the listen thread has the time to execute the SELECT statement. Since the command thread didn't commit yet, the SELECT returns nothing. Finally, the command thread commits, without notifying anyone. Hmm ... yup, that's a race condition all right, and of sufficiently low probability that it's not surprising it's gone undetected for so long. In Async_Listen(): change 'heap_close(lRel, ExclusiveLock);' for 'heap_close(lRel, NoLock);'. This solution is pretty ugly, though, because we allow people to execute LISTEN/UNLISTEN in transaction blocks, which means that the ExclusiveLock could be held for quite some time. Not only is that bad for performance but it poses significant risks of deadlocks. What I am thinking is that we need to change LISTEN/UNLISTEN so that they don't attempt to modify the pg_listener table until COMMIT time. It would go about like this: 1. LISTEN and UNLISTEN would make entries in a transaction-lifespan list, much as NOTIFY does, with suitable logic to cancel each others' effects on the list as needed. They don't touch pg_listener at all. 2. If we abort the transaction then the list of pending actions is just thrown away. (Hmm, we'd also need to account for subtransactions...) 3. If we commit, then AtCommit_Notify is responsible for applying any pg_listener insertions and deletions indicated by the pending-actions list, after it grabs ExclusiveLock and before it starts the notify loop. (A CommandCounterIncrement between this step and the notify loop will assure that LISTEN and NOTIFY in the same transaction result in a self-notify just as before.) Since AtCommit_Notify doesn't release the lock, the race condition is fixed, and since it only happens immediately before commit, there is no added risk of deadlock. The only externally visible difference in behavior is that it's less likely for failed LISTENing transactions to leave dead tuples in pg_listener. There is an *internally* visible difference, in that a sequence like BEGIN; LISTEN foo; SELECT ... FROM pg_listener ... COMMIT; will fail to see any tuple from the LISTEN in pg_listener, where historically it did. I suppose it's conceivable that some application out there depends on this, but it doesn't seem very likely. (Slony guys want to speak up here?) Comments? Have I missed anything? Looking at this sketch, my first reaction is that it's a lot of code to write in support of an implementation we hope to throw away soon. But my second reaction is that we're going to need most of that code anyway in a pg_listener-less implementation, because the module will have to emulate the current transactional behavior of LISTEN/UNLISTEN without any table to store rows in. So there should be something salvageable from the effort. Assuming that we implement this (I'm willing to write the code), is it sane to back-patch such a non-trivial change? It's a bit scary but on the other hand we've back-patched larger changes when we had to. Leaving the race condition in place isn't appetizing, and neither is introducing deadlock risks that weren't there before. 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] LISTEN/NOTIFY race condition?
In Async_Listen(): change 'heap_close(lRel, ExclusiveLock);' for 'heap_close(lRel, NoLock);'. This solution is pretty ugly, though, because we allow people to execute LISTEN/UNLISTEN in transaction blocks, which means that the ExclusiveLock could be held for quite some time. Not only is that bad for performance but it poses significant risks of deadlocks. True, I had not considered this. Comments? Have I missed anything? As far as I can tell it seems fine. Thanks a lot for your input! Laurent Birtz -- 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 #4024: xpath() results lose namespace mappings
The following bug has been logged online:
Bug reference: 4024
Logged by: Matt Magoffin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.0
Operating system: OS X 10.5, Windows XP
Description:xpath() results lose namespace mappings
Details:
I was trying to extract XML fragments within a pl/pgsql function by nested
xpath() function calls, and found that when namespaces are used in the
XML, only the first xpath() call is able to correctly use namespaces.
First here is an example that works, when no namespaces are used:
BEGIN;
CREATE TEMPORARY TABLE tmp_xpath_test (x xml) ON COMMIT DROP;
INSERT INTO tmp_xpath_test VALUES (
'foobar x=ybar1/barbar x=ybar2/bar/foo'::xml);
SELECT (xpath('/foo/bar[1]', t.x))[1] FROM tmp_xpath_test t;
SELECT xpath('/bar/@x', (xpath('/foo/bar[1]', t.x))[1]) FROM
tmp_xpath_test t;
COMMIT;
The first select is just there to show the result of the inner call to
xpath() in the second select, and the second select returns:
SELECT xpath('/bar/@x', (xpath('/foo/bar[1]', t.x))[1]) FROM
tmp_xpath_test t;
xpath
---
{y}
(1 row)
Now if I use XML with namespaces, the first SELECT works, but the second
never returns the expected results:
BEGIN;
CREATE TEMPORARY TABLE tmp_xpath_test (x xml) ON COMMIT DROP;
INSERT INTO tmp_xpath_test VALUES (
'a:foo xmlns:a=a:urna:bar x=ybar1/a:bara:bar
x=ybar2/a:bar/a:foo'::xml);
SELECT (xpath('/a:foo/a:bar[1]', t.x, ARRAY[ARRAY['a','a:urn']]))[1] FROM
tmp_xpath_test t;
SELECT xpath('/a:bar/@x', (xpath('/a:foo/a:bar[1]', t.x,
ARRAY[ARRAY['a','a:urn']]))[1],
ARRAY[ARRAY['a','a:urn']]) FROM tmp_xpath_test t;
COMMIT;
The select results are
SELECT (xpath('/a:foo/a:bar[1]', t.x, ARRAY[ARRAY['a','a:urn']]))[1] FROM
tmp_xpath_test t;
xpath
---
a:bar x=ybar1/a:bar
(1 row)
SELECT xpath('/a:bar/@x', (xpath('/a:foo/a:bar[1]', t.x,
ARRAY[ARRAY['a','a:urn']]))[1],
lms_kia( ARRAY[ARRAY['a','a:urn']]) FROM tmp_xpath_test t;
xpath
---
{}
(1 row)
For the second select, I expected a single XML text node containing y,
just like from the no-namespace result.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
