Re: [BUGS] BUG #5081: ON INSERT rule does not work correctly
"Stefan" writes: > The problem is that if it is no record in the table, it seems that first the > INSERT command is issued and after that the UPDATE command is issued, too. Well, yeah. That's exactly how it's documented to work: an ON INSERT rule is executed after the INSERT proper. You could maybe make this work with a BEFORE INSERT trigger. 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: [JDBC] [BUGS] BUG #5058: [jdbc] Silent failure with executeUpdate()
On Thu, 17 Sep 2009, Joseph Shraibman wrote:
[when passing a multi-statement sql string to executeUpdate, if a
statement after the first is a select, it is silently not fully
executed.]
Running queries in executeUpdate is not allowed. If you pass a plain
select to executeUpdate it complains: stmt.executeUpdate("SELECT 1");
org.postgresql.util.PSQLException: A result was returned when none was
expected.
The problem here is that we don't complain if it's not the first part of a
multi-part statement. stmt.executeUpdate("/* */; SELECT 1") does not
produce an error, but should, which I believe is the bug in this case.
Since the JDBC driver knows it's going to complain if it sees a query
result during executeUpdate, it wants to avoid the possibility of the user
issuing a query which returns a giant dataset and having to process that
just to error out anyway. So it passes the statements to the server with
an additional instruction to say, "I just want the first row back at this
time". That way if it is a big query result we'll only get one row
instead of the whole thing. The server can implement this by either
holding the whole resultset on the server or, as in this case, partially
executing the query and returning control to the driver to see if it wants
to continue executing it. So your select is only partially executed,
getting run for only one row of the "joa" table rather than the whole
thing as you are expecting.
I intend to change the driver to error out in this case.
Kris Jurka
--
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 #5076: LEFT OUTER JOIN and WHERE madness
"Mauro Infantino" writes: > I'm just experiencing the same as in here, > http://archives.postgresql.org/pgsql-bugs/2008-06/msg00175.php > It was not happening for 8.3.7 (at least on Windows). This is the very definition of an unhelpful bug report. You are not seeing the same thing that was reported against 8.3.3, because that bug is fixed --- there's a regression test proving so. You might be seeing something else with a similar symptom, but with no details or test case, there is nothing we can do about it. 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 #5079: postgres killed by signal 11 when executing xslt_process function from xml2 contrib module.
"dolejsi jiri" writes: > executing following query 2 times crashes postgres server: The stack trace is #0 0x003d7e42e989 in xmlCleanupCharEncodingHandlers () from /usr/lib64/libxml2.so.2 #1 0x003d7e437725 in xmlCleanupParser () from /usr/lib64/libxml2.so.2 #2 0x7fac004e270d in xslt_process (fcinfo=0x7fff59701da0) at xslt_proc.c:124 #3 0x00566154 in ExecMakeFunctionResult ( fcache=, econtext=, isNull=0x7fff5970222f "", isDone=0x0) at execQual.c:1686 #4 0x0056141c in ExecEvalExprSwitchContext (expression=0x7, econtext=0x0, isNull=0x1c258a0 '\177' ..., isDone=0x1c25870) at execQual.c:4030 which is probably sufficient evidence that this is another variant of the known memory management issues with contrib/xml2: http://archives.postgresql.org/message-id/4a6a276a.6090...@dunslane.net So far no one has mustered the interest/energy to fix it. 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
