Re: Updateable cursors patch

Cool patch.

On Wed, 2007-04-04 at 18:36 +0000, 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 the planner take a SeqScan, then override this at the top of
the executor? So if we EXPLAIN this it would say "SeqScan", but doesn't
actually do that? It works, but you're right it should do this the same
way as other plan types.

ISTM you need to add a special case in set_plain_rel_pathlist() in
optimizer/paths/allpaths.c similar to the special case for
relation_excluded_by_constraints(). In the case of an updateable cursor
there is only one path we want it to take, so a shortcut out is
appropriate, so the code would look similar-ish. Then you need to teach
the tidscan node to handle the case for an updateable cursor, i.e. a
call similar to GetCursorSlot() in TidNext() in nodeTidscan.c. That way
the rest of the executor machinery can get the slot for you.

Do we need additional code in any of the clients to handle this new
functionality correctly? ECPG etc?

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

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.

---------------------------------------------------------------------------

FAST PostgreSQL wrote:
> Attached is a working updateable cursors patch. The core functionality has
> been implemented and the patch also contains the regression tests and
> documentation.
>
> However there are still a couple of TODOs that needs to be done. 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. Also, an issue that needs to
> be looked at is how to treat joins with an updateable cursor. Currently it is
> allowed and when it comes to delete or update, an error message is thrown
> from the executor.
>
> Rgds,
> Arul Shaji
>
>

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Mon, 2 Apr 2007 03:15, Simon Riggs wrote:
> Cool patch.
>
> On Wed, 2007-04-04 at 18:36 +0000, 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 the planner take a SeqScan, then override this at the top of
> the executor? So if we EXPLAIN this it would say "SeqScan", but doesn't
> actually do that? It works, but you're right it should do this the same
> way as other plan types.
>

Yeah, currently EXPLAIN will give the wrong details. That's not ideal of
course. We will be fixing that soon. Thanks for the code tips.

> ISTM you need to add a special case in set_plain_rel_pathlist() in
> optimizer/paths/allpaths.c similar to the special case for
> relation_excluded_by_constraints(). In the case of an updateable cursor
> there is only one path we want it to take, so a shortcut out is
> appropriate, so the code would look similar-ish. Then you need to teach
> the tidscan node to handle the case for an updateable cursor, i.e. a
> call similar to GetCursorSlot() in TidNext() in nodeTidscan.c. That way
> the rest of the executor machinery can get the slot for you.
>
> Do we need additional code in any of the clients to handle this new
> functionality correctly? ECPG etc?
Psql's tab completion is one that quickly comes to mind. Along with the above
said fix, I can do this. Don't know too much about other clients....

Rgds,
Arul Shaji

Attached is a working updateable cursors patch. The core functionality has
been implemented and the patch also contains the regression tests and
documentation.

However there are still a couple of TODOs that needs to be done. 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. Also, an issue that needs to
be looked at is how to treat joins with an updateable cursor. Currently it is
allowed and when it comes to delete or update, an error message is thrown
from the executor.

Rgds,
Arul Shaji

On 4/4/07, FAST PostgreSQL <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au> 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
http://archives.postgresql.org/pgsql-committers/2007-04/msg00447.php

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

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 <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au> 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
> http://archives.postgresql.org/pgsql-committers/2007-04/msg00447.php
>

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 wrote:
> 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 <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au> 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
>> http://archives.postgresql.org/pgsql-committers/2007-04/msg00447.php
>>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
>

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.

---------------------------------------------------------------------------

FAST PostgreSQL wrote:
> 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 wrote:
> > 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 <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au> 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
> >> http://archives.postgresql.org/pgsql-committers/2007-04/msg00447.php
> >>
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: explain analyze is your friend
> >
> >

>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
> http://www.postgresql.org/about/donate

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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 <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>:
> 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 wrote:
> > 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 <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au> 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
> >> http://archives.postgresql.org/pgsql-committers/2007-04/msg00447.php
> >>
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: explain analyze is your friend
> >
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
> http://www.postgresql.org/about/donate
>
>
>

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 the sql standards.)

I can update the documentation once the initial review is done and what
I have done gets atleast a pass mark :-)

Rgds,
Arul Shaji

Pavel Stehule wrote:
> 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 <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>:
>> 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 wrote:
>> > 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 <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au> 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
>> >> http://archives.postgresql.org/pgsql-committers/2007-04/msg00447.php
>> >>
>> >
>> >
>> > ---------------------------(end of
>> broadcast)---------------------------
>> > TIP 6: explain analyze is your friend
>> >
>> >
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 7: You can help support the PostgreSQL project by donating at
>>
>> http://www.postgresql.org/about/donate
>>
>>
>>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
>

On 5/17/07, FAST PostgreSQL <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au> 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 the order by clause, the
> implementation is as per the sql standards.)
>

your patch doesn't work with updatable views because they don't have
ctid columns....

ERROR: column "ctid" does not exist
STATEMENT: update vfoo set des_cta = des_cta || ' - prueba' where
current of foo;
ERROR: current transaction is aborted, commands ignored until end of
transaction block

is this sane behavior? to accept create cursors for update on views
and then failing to update "where current of" and rollback the entire
transaction?

comments?

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

On 5/17/07, Jaime Casanova <systemguards(at)gmail(dot)com> wrote:
> On 5/17/07, FAST PostgreSQL <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au> 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 the order by clause, the
> > implementation is as per the sql standards.)
> >
>
> your patch doesn't work with updatable views because they don't have
> ctid columns....
>
> ERROR: column "ctid" does not exist
> STATEMENT: update vfoo set des_cta = des_cta || ' - prueba' where
> current of foo;
> ERROR: current transaction is aborted, commands ignored until end of
> transaction block
>
> is this sane behavior? to accept create cursors for update on views
> and then failing to update "where current of" and rollback the entire
> transaction?
>
> comments?
>

sorry, reattaching the test script

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

2007/5/18, FAST PostgreSQL <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>:
> 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 the sql standards.)

some scrollable cursors are materialised. It depends on query :-(.
Simple query without join can works.

regards

Pavel

>
> I can update the documentation once the initial review is done and what
> I have done gets atleast a pass mark :-)
>
> Rgds,
> Arul Shaji
>
>
> Pavel Stehule wrote:
> > 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 <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>:
> >> 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 wrote:
> >> > 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 <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au> 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
> >> >> http://archives.postgresql.org/pgsql-committers/2007-04/msg00447.php
> >> >>
> >> >
> >> >
> >> > ---------------------------(end of
> >> broadcast)---------------------------
> >> > TIP 6: explain analyze is your friend
> >> >
> >> >
> >>
> >>
> >> ---------------------------(end of broadcast)---------------------------
> >> TIP 7: You can help support the PostgreSQL project by donating at
> >>
> >> http://www.postgresql.org/about/donate
> >>
> >>
> >>
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/docs/faq
> >
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

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 wrote:
> 2007/5/18, FAST PostgreSQL <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>:
>> 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 the sql standards.)
>
> some scrollable cursors are materialised. It depends on query :-(.
> Simple query without join can works.
>
> regards
>
> Pavel
>
>>
>> I can update the documentation once the initial review is done and what
>> I have done gets atleast a pass mark :-)
>>
>> Rgds,
>> Arul Shaji
>>
>>
>> Pavel Stehule wrote:
>> > 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 <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>:
>> >> 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 wrote:
>> >> > 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 <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au> 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
>> >> >>
>> http://archives.postgresql.org/pgsql-committers/2007-04/msg00447.php
>> >> >>
>> >> >
>> >> >
>> >> > ---------------------------(end of
>> >> broadcast)---------------------------
>> >> > TIP 6: explain analyze is your friend
>> >> >
>> >> >
>> >>
>> >>
>> >> ---------------------------(end of
>> broadcast)---------------------------
>> >> TIP 7: You can help support the PostgreSQL project by donating at
>> >>
>> >> http://www.postgresql.org/about/donate
>> >>
>> >>
>> >>
>> >
>> > ---------------------------(end of
>> broadcast)---------------------------
>> > TIP 3: Have you checked our extensive FAQ?
>> >
>> > http://www.postgresql.org/docs/faq
>> >
>> >
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 1: if posting/reading through Usenet, please send an appropriate
>> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>> message can get through to the mailing list cleanly
>>
>
>

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
> scrollable. So maybe I should put an explicit check during cursor
> creation disallowing scrollable updateable cursors.
>
> Rgds,
> Arul Shaji
>
>
> Pavel Stehule wrote:
>> 2007/5/18, FAST PostgreSQL <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>:
>>> 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 the sql standards.)
>>
>> some scrollable cursors are materialised. It depends on query :-(.
>> Simple query without join can works.
>>
>> regards
>>
>> Pavel
>>
>>>
>>> I can update the documentation once the initial review is done and what
>>> I have done gets atleast a pass mark :-)
>>>
>>> Rgds,
>>> Arul Shaji
>>>
>>>
>>> Pavel Stehule wrote:
>>> > 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 <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>:
>>> >> 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 wrote:
>>> >> > 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 <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au> 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
>>> >> >>
>>> http://archives.postgresql.org/pgsql-committers/2007-04/msg00447.php
>>> >> >>
>>> >> >
>>> >> >
>>> >> > ---------------------------(end of
>>> >> broadcast)---------------------------
>>> >> > TIP 6: explain analyze is your friend
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >> ---------------------------(end of
>>> broadcast)---------------------------
>>> >> TIP 7: You can help support the PostgreSQL project by donating at
>>> >>
>>> >> http://www.postgresql.org/about/donate
>>> >>
>>> >>
>>> >>
>>> >
>>> > ---------------------------(end of
>>> broadcast)---------------------------
>>> > TIP 3: Have you checked our extensive FAQ?
>>> >
>>> > http://www.postgresql.org/docs/faq
>>> >
>>> >
>>>
>>>
>>> ---------------------------(end of broadcast)---------------------------
>>> TIP 1: if posting/reading through Usenet, please send an appropriate
>>> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>>> message can get through to the mailing list cleanly
>>>
>>
>>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
>

2007/5/18, FAST PostgreSQL <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>:
> 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.

I am for it. It good protection before strange bugs

Pavel

>
> Rgds,
> Arul Shaji
>
>
> Pavel Stehule wrote:
> > 2007/5/18, FAST PostgreSQL <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>:
> >> 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 the sql standards.)
> >
> > some scrollable cursors are materialised. It depends on query :-(.
> > Simple query without join can works.
> >
> > regards
> >
> > Pavel
> >
> >>
> >> I can update the documentation once the initial review is done and what
> >> I have done gets atleast a pass mark :-)
> >>
> >> Rgds,
> >> Arul Shaji
> >>
> >>
> >> Pavel Stehule wrote:
> >> > 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 <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>:
> >> >> 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 wrote:
> >> >> > 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 <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au> 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
> >> >> >>
> >> http://archives.postgresql.org/pgsql-committers/2007-04/msg00447.php
> >> >> >>
> >> >> >
> >> >> >
> >> >> > ---------------------------(end of
> >> >> broadcast)---------------------------
> >> >> > TIP 6: explain analyze is your friend
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >> ---------------------------(end of
> >> broadcast)---------------------------
> >> >> TIP 7: You can help support the PostgreSQL project by donating at
> >> >>
> >> >> http://www.postgresql.org/about/donate
> >> >>
> >> >>
> >> >>
> >> >
> >> > ---------------------------(end of
> >> broadcast)---------------------------
> >> > TIP 3: Have you checked our extensive FAQ?
> >> >
> >> > http://www.postgresql.org/docs/faq
> >> >
> >> >
> >>
> >>
> >> ---------------------------(end of broadcast)---------------------------
> >> TIP 1: if posting/reading through Usenet, please send an appropriate
> >> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> >> message can get through to the mailing list cleanly
> >>
> >
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>

On 5/17/07, Jaime Casanova <systemguards(at)gmail(dot)com> wrote:
> On 5/17/07, FAST PostgreSQL <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au> 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 the order by clause, the
> > implementation is as per the sql standards.)
> >
>
> your patch doesn't work with updatable views because they don't have
> ctid columns....
>
> ERROR: column "ctid" does not exist
> STATEMENT: update vfoo set des_cta = des_cta || ' - prueba' where
> current of foo;
> ERROR: current transaction is aborted, commands ignored until end of
> transaction block
>
> is this sane behavior? to accept create cursors for update on views
> and then failing to update "where current of" and rollback the entire
> transaction?
>
> comments?
>

maybe just send a better error message

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

>
> 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 thrown if there are no rules. It
is easily doable. But I want to confirm if this will break any other
part. I am looking into it now.

Rgds,
Arul Shaji

Jaime Casanova wrote:
> On 5/17/07, Jaime Casanova <systemguards(at)gmail(dot)com> wrote:
>> On 5/17/07, FAST PostgreSQL <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au> 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 the order by clause, the
>> > implementation is as per the sql standards.)
>> >
>>
>> your patch doesn't work with updatable views because they don't have
>> ctid columns....
>>
>> ERROR: column "ctid" does not exist
>> STATEMENT: update vfoo set des_cta = des_cta || ' - prueba' where
>> current of foo;
>> ERROR: current transaction is aborted, commands ignored until end of
>> transaction block
>>
>> is this sane behavior? to accept create cursors for update on views
>> and then failing to update "where current of" and rollback the entire
>> transaction?
>>
>> comments?
>>
>
> maybe just send a better error message
>