Barry Lind <barry@xythos.com> writes:
> Is this behavior intended in the backend? The problem is that when you
> create a rule on an object that calls a stored function and invoke that
> rule on an insert/update/delete statement your insert/update/delete
> statement will now return a query result to the front end over the FE/BE
> protocol. (I am not sure this is the exact senerio, but something
> similar).
If the rule adds SELECT operations to the basic statement then those
SELECT(s) will return results to the frontend. I think this is
appropriate, perhaps even necessary for some applications of rules.
> This means that the user now needs to perform a
> executeQuery() call when using these insert/update/delete statements in
> JDBC because the JDBC driver isn't able to accept a query response when
> issuing a insert/update/delete call.
I would regard that as a JDBC bug: it should be able to accept a query
response at any time. It shouldn't have preconceived ideas about what
a given query will produce.
It probably would be a good idea to add some kind of "CALL" or "PERFORM"
statement to the backend, having the same semantics as SELECT except
that the query result is discarded instead of being shipped to the
client. However, this is largely syntactic sugar with maybe a tiny
bit of performance-improvement rationale. JDBC should be able to cope
with all the cases that libpq does, and libpq handles this scenario
with aplomb.
regards, tom lane
