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-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.