Re: server side prepare breaks view inserts
"Greg Sabino Mullane" <greg-738XdyZ4GzZWk0Htik3J/[email protected]>
| Newsgroups | gmane.comp.db.postgresql.dbdpg |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> it seems to be that when using { pg_server_prepare => 1 }
> then I can't get back the result table of the insert function triggered
> by the insert rule of a view.
> ...
> Running with { pg_server_prepare => 1 }
> Fetching the new id...
> DBD::Pg::st fetchrow_array failed: no statement executing
> ...
> Please somebody try to explain this phenomena...
What's happening is that when are using pg_server_prepare, DBD::Pg is
using PQexecParams or PQexecPrepared. These do not support multi-statement
returns. PQexec, on the other hand, returns the last statement executed.
The libpq docs mention that this is done for "backwards compatibility",
so it's not a feature I would rely upon in the future.
To put this another way, when you run your query, Postgres is returning
"PGRES_COMMAND_OK", followed by a "PGRES_TUPLES_OK". Seeing the latter
one is what tells us that some data is ready to be fetched. However,
only PQexec (e.g. pg_server_prepare => 0) sees the PGRES_TUPLES_OK result,
and this is more of a side-effect than a feature.
I'm not sure what the solution is, as this may require a libpq and/or
protocol-level change, if you can convince people that this is a bug and
not a feature. :) I'll bring this up on hackers. From your point of view,
the best thing is to avoid using such rules that change from a non tuple
returning query to a tuple returning query, or to set pg_server_prepare = 0.
- --
Greg Sabino Mullane greg-738XdyZ4GzZWk0Htik3J/[email protected]
PGP Key: 0x14964AC8 200605170831
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iD8DBQFEaxe+vJuQZxSWSsgRAi+AAKCQLCQ6Bjkgh5L4i16mByUAHSIaiwCeN4Er
mJQq083VhiJntP1xzLUyLMM=
=qLZI
-----END PGP SIGNATURE-----