Re: insert/update/delete statements returning a query response
От | Tom Lane |
---|---|
Тема | Re: insert/update/delete statements returning a query response |
Дата | |
Msg-id | 16056.1006817809@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | insert/update/delete statements returning a query response (Barry Lind <barry@xythos.com>) |
Ответы |
Re: insert/update/delete statements returning a query
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: