Thread: patch fixing the old RETURN NEXT bug

Hello All,

I'm proposing the fix of this bug:
http://archives.postgresql.org/pgsql-hackers/2005-02/msg00498.php

The exact SQL code exposing the error:

----------

create table usno (ra real, dec real, bmag real, rmag real,ipix int8);
CREATE OR REPLACE FUNCTION xxx(refcursor) RETURNS refcursor AS '
DECLARE query varchar;
BEGIN
query = ''SELECT * FROM usno'';
OPEN $1 FOR EXECUTE query;
RETURN $1;
END;
' LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION yyy() RETURNS SETOF usno AS '
DECLARE rec record;
DECLARE cur refcursor;
BEGIN
cur=xxx(''curs_name'');
LOOP
        FETCH cur into rec;
        EXIT WHEN NOT FOUND;
        RETURN NEXT rec;
END LOOP;
RETURN;
END;
' LANGUAGE plpgsql;

insert into usno values(1,2,3,4);
select * from yyy();
alter table usno add column errbox box;
select * from yyy();
alter table usno drop column errbox;
select * from yyy();

-------

The problem with that is in fact in pl_exec.c in function
compatible_tupdesc(), which do not check for the deleted attributes.

The patch is attached.

Regards,
    Sergey

*****************************************************
Sergey E. Koposov
Max Planck Institute for Astronomy
Web: http://lnfm1.sai.msu.ru/~math
E-mail: math@sai.msu.ru

"Sergey E. Koposov" <math@sai.msu.ru> writes:
> The problem with that is in fact in pl_exec.c in function
> compatible_tupdesc(), which do not check for the deleted attributes.

Is that really the only problem?

            regards, tom lane

On Sun, 12 Feb 2006, Tom Lane wrote:

> "Sergey E. Koposov" <math@sai.msu.ru> writes:
> > The problem with that is in fact in pl_exec.c in function
> > compatible_tupdesc(), which do not check for the deleted attributes.
>
> Is that really the only problem?

I cannot be completely sure in that, but at least the submitted patch
eliminate the problem with the SQL code from my previous email.

Regards,
    Sergey

*****************************************************
Sergey E. Koposov
Max Planck Institute for Astronomy
Web: http://lnfm1.sai.msu.ru/~math
E-mail: math@sai.msu.ru

On Sun, 12 Feb 2006, Tom Lane wrote:
> "Sergey E. Koposov" <math@sai.msu.ru> writes:
> > The problem with that is in fact in pl_exec.c in function
> > compatible_tupdesc(), which do not check for the deleted attributes.
>
> Is that really the only problem?

Tom,

Are there any problems with that patch to not be applied ?
(Sorry if I'm hurrying)

Regards,
    Sergey

*****************************************************
Sergey E. Koposov
Max Planck Institute for Astronomy
Web: http://lnfm1.sai.msu.ru/~math
E-mail: math@sai.msu.ru

"Sergey E. Koposov" <math@sai.msu.ru> writes:
> Are there any problems with that patch to not be applied ?

Hasn't been reviewed yet ... see nearby discussions about shortage
of patch reviewers ...

> (Sorry if I'm hurrying)

At the moment it's not unusual for nontrivial patches to sit around
for a month or two, unless they happen to attract special interest of
one of the committers.

            regards, tom lane

On Sun, 2006-02-12 at 20:15 +0300, Sergey E. Koposov wrote:
> I'm proposing the fix of this bug:
> http://archives.postgresql.org/pgsql-hackers/2005-02/msg00498.php

I think the suggested logic for compatible_tupdesc() is still wrong. For
example, the patch rejects the following:

create table usno (ra real, dec real, bmag real, rmag real, ipix int8);
create function ret_next_check() returns setof usno as $$
declare
    r record;
begin
    for r in select * from usno loop
        return next r;
    end loop;
    return;
end;
$$ language plpgsql;

insert into usno values (1.0, 2.0, 3.0, 4.0, 5);
select * from ret_next_check();
alter table usno drop column ipix;
select * from ret_next_check(); -- fails, should succeed

Also, this patch should include updates to the regression tests.

-Neil

Needs cleaning up.

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.

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


Neil Conway wrote:
> On Sun, 2006-02-12 at 20:15 +0300, Sergey E. Koposov wrote:
> > I'm proposing the fix of this bug:
> > http://archives.postgresql.org/pgsql-hackers/2005-02/msg00498.php
>
> I think the suggested logic for compatible_tupdesc() is still wrong. For
> example, the patch rejects the following:
>
> create table usno (ra real, dec real, bmag real, rmag real, ipix int8);
> create function ret_next_check() returns setof usno as $$
> declare
>     r record;
> begin
>     for r in select * from usno loop
>         return next r;
>     end loop;
>     return;
> end;
> $$ language plpgsql;
>
> insert into usno values (1.0, 2.0, 3.0, 4.0, 5);
> select * from ret_next_check();
> alter table usno drop column ipix;
> select * from ret_next_check(); -- fails, should succeed
>
> Also, this patch should include updates to the regression tests.
>
> -Neil
>
>
>
> ---------------------------(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
>

--
  Bruce Momjian   http://candle.pha.pa.us
  SRA OSS, Inc.   http://www.sraoss.com

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

Added to TODO:

       o Fix problems with RETURN NEXT on tables with
         dropped/added columns after function creation

          http://archives.postgresql.org/pgsql-patches/2006-02/msg00165$


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

Sergey E. Koposov wrote:
> Hello All,
>
> I'm proposing the fix of this bug:
> http://archives.postgresql.org/pgsql-hackers/2005-02/msg00498.php
>
> The exact SQL code exposing the error:
>
> ----------
>
> create table usno (ra real, dec real, bmag real, rmag real,ipix int8);
> CREATE OR REPLACE FUNCTION xxx(refcursor) RETURNS refcursor AS '
> DECLARE query varchar;
> BEGIN
> query = ''SELECT * FROM usno'';
> OPEN $1 FOR EXECUTE query;
> RETURN $1;
> END;
> ' LANGUAGE plpgsql;
>
> CREATE OR REPLACE FUNCTION yyy() RETURNS SETOF usno AS '
> DECLARE rec record;
> DECLARE cur refcursor;
> BEGIN
> cur=xxx(''curs_name'');
> LOOP
>         FETCH cur into rec;
>         EXIT WHEN NOT FOUND;
>         RETURN NEXT rec;
> END LOOP;
> RETURN;
> END;
> ' LANGUAGE plpgsql;
>
> insert into usno values(1,2,3,4);
> select * from yyy();
> alter table usno add column errbox box;
> select * from yyy();
> alter table usno drop column errbox;
> select * from yyy();
>
> -------
>
> The problem with that is in fact in pl_exec.c in function
> compatible_tupdesc(), which do not check for the deleted attributes.
>
> The patch is attached.
>
> Regards,
>     Sergey
>
> *****************************************************
> Sergey E. Koposov
> Max Planck Institute for Astronomy
> Web: http://lnfm1.sai.msu.ru/~math
> E-mail: math@sai.msu.ru
>

Content-Description:

[ Attachment, skipping... ]

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

--
  Bruce Momjian   http://candle.pha.pa.us
  EnterpriseDB    http://www.enterprisedb.com

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