I'm looking at modifying the portal execution strategy so that INSERT
RETURNING and friends will work when invoked through extended query
protocol. Currently, INSERT/UPDATE/DELETE queries are always executed
under PORTAL_MULTI_QUERY strategy, which runs the portal's queries to
completion and
Sorry, copied to list.
On 8/11/06, Tom Lane [EMAIL PROTECTED] wrote:
3. Throw an error (thereby rolling back the incomplete update)
if client closes the portal without having run it to completion.
Sounds like the most reasonable considering. I'm not averse to it.
4. Treat
1. Define it as a feature not a bug. People do occasionally ask for
UPDATE foo ... LIMIT 1 after all. But this is a pretty klugy way of
getting that, and the arguments that say allowing LIMIT on updating
queries would be a bad idea haven't lost their force.
Being one of those who was asking
Jonah H. Harris [EMAIL PROTECTED] writes:
On 8/11/06, Tom Lane [EMAIL PROTECTED] wrote:
4. Treat PORTAL_ONE_RETURNING like PORTAL_UTIL_SELECT rather than
like PORTAL_ONE_SELECT; that is, execute the query to completion
on first call and stash the results in a tuplestore until the
client
On 8/11/06, Tom Lane [EMAIL PROTECTED] wrote:
Not really. Locks and so forth held by the query would be held till
commit in any case, so I don't see much advantage in finishing the
query immediately.
Very true.
--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB
Jonah H. Harris [EMAIL PROTECTED] writes:
On 8/11/06, Tom Lane [EMAIL PROTECTED] wrote:
4. Treat PORTAL_ONE_RETURNING like PORTAL_UTIL_SELECT rather than
like PORTAL_ONE_SELECT; that is, execute the query to completion
on first call and stash the results in a tuplestore until the
client
