maybe just send a better error message
I do the transformation of a where current of clause into where clause
at the analyze stage itself(which is the right place to do. I think).
Hence this error. If I can postpone this transformation until after
re-write then the usual error will be
On 5/17/07, Jaime Casanova [EMAIL PROTECTED] wrote:
On 5/17/07, FAST PostgreSQL [EMAIL PROTECTED] wrote:
No. It works with scrollable cursors. It will work for cursors/selects
which does not put the results in some store, such as WITH hold/group
by/order by etc But most of these
Right. The current implementation allows only simple queries. Joins are
disallowed. According to the standard, updateable cursors cannot be
scrollable. So maybe I should put an explicit check during cursor
creation disallowing scrollable updateable cursors.
Rgds,
Arul Shaji
Pavel Stehule
Correction Meant to say
According to the standard, updateable cursors cannot be scrollable until
we have full cursor update.
FAST PostgreSQL wrote:
Right. The current implementation allows only simple queries. Joins are
disallowed. According to the standard, updateable cursors cannot be
2007/5/18, FAST PostgreSQL [EMAIL PROTECTED]:
Right. The current implementation allows only simple queries. Joins are
disallowed. According to the standard, updateable cursors cannot be
scrollable. So maybe I should put an explicit check during cursor
creation disallowing scrollable updateable
Attached is an updated version of the updateable cursors patch against
the latest cvs head.
Most of the changes in the patch are to make it sync with the changes in
CVS recently, for DECLARE CURSOR and EXPLAIN, as mentioned by Jaime in
his mail below.
Rgds,
Arul Shaji
FAST PostgreSQL
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Hello
I am not sure, but your solution will faill on scrollable cursors
(it's similar to holdable cursors). I miss part about limits in
documentation. Propably updatable cursors aren't supported by plpgsql
(and it's point to ToDo).
Regards
Pavel Stehule
2007/5/17, FAST PostgreSQL [EMAIL
No. It works with scrollable cursors. It will work for cursors/selects
which does not put the results in some store, such as WITH hold/group
by/order by etc But most of these restrictions apply for normal
'Select for update' anyway. (With the order by clause, the
implementation is as per
On 5/17/07, FAST PostgreSQL [EMAIL PROTECTED] wrote:
No. It works with scrollable cursors. It will work for cursors/selects
which does not put the results in some store, such as WITH hold/group
by/order by etc But most of these restrictions apply for normal
'Select for update' anyway. (With
On 5/17/07, Jaime Casanova [EMAIL PROTECTED] wrote:
On 5/17/07, FAST PostgreSQL [EMAIL PROTECTED] wrote:
No. It works with scrollable cursors. It will work for cursors/selects
which does not put the results in some store, such as WITH hold/group
by/order by etc But most of these
2007/5/18, FAST PostgreSQL [EMAIL PROTECTED]:
No. It works with scrollable cursors. It will work for cursors/selects
which does not put the results in some store, such as WITH hold/group
by/order by etc But most of these restrictions apply for normal
'Select for update' anyway. (With the
Right. I will send an updated patch against the CVS head in the next
couple of days.
Jaime Casanova wrote:
On 4/4/07, FAST PostgreSQL [EMAIL PROTECTED] wrote:
Attached is a working updateable cursors patch. The core functionality
has
been implemented and the patch also contains the
On 4/4/07, FAST PostgreSQL [EMAIL PROTECTED] wrote:
Attached is a working updateable cursors patch. The core functionality has
been implemented and the patch also contains the regression tests and
documentation.
this one doesn't apply cleanly to HEAD because of the changes in
On Mon, 2 Apr 2007 03:15, Simon Riggs wrote:
Cool patch.
On Wed, 2007-04-04 at 18:36 +, FAST PostgreSQL wrote:
The planner has to be taught to treat a DELETE/UPDATE WHERE CURRENT OF
as a TidScan. Currently it follows the sequential scan route and
extracts the current tuple based on
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Cool patch.
On Wed, 2007-04-04 at 18:36 +, FAST PostgreSQL wrote:
The planner has to be taught to treat a DELETE/UPDATE WHERE CURRENT OF
as a TidScan. Currently it follows the sequential scan route and
extracts the current tuple based on the cursor position from the
portal.
So you let
17 matches
Mail list logo
