Re: Strange RETURN NEXT behaviour in Postgres 8.0

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Richard Huxton <dev(at)archonet(dot)com>
Cc: "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Strange RETURN NEXT behaviour in Postgres 8.0
Date: 2005-02-17 00:38:42
Message-ID: 1149.1108600722@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Richard Huxton <dev(at)archonet(dot)com> writes:
> I seem to remember some subtle problems with dropped columns and plpgsql
> functions - could be one of those still left.

For instance:

regression=# create table usno (ra real, dec real, bmag real, rmag real,ipix int8);
CREATE TABLE
regression=# [ create Sergey's functions ]
regression=# insert into usno values(1,2,3,4);
INSERT 1132435 1
regression=# select * from yyy();
ra | dec | bmag | rmag | ipix
----+-----+------+------+------
1 | 2 | 3 | 4 |
(1 row)

regression=# alter table usno add column errbox box;
ALTER TABLE
regression=# select * from yyy();
ra | dec | bmag | rmag | ipix | errbox
----+-----+------+------+------+--------
1 | 2 | 3 | 4 | |
(1 row)

regression=# alter table usno drop column errbox;
ALTER TABLE
regression=# select * from yyy();
ERROR: wrong record type supplied in RETURN NEXT
CONTEXT: PL/pgSQL function "yyy" line 8 at return next
regression=#

It looks like the code that handles returning a RECORD variable doesn't
cope with dropped columns in the function result rowtype.

(If you instead declare rec as usno%rowtype, you get a different set
of misbehaviors after adding/dropping columns, so that code path isn't
perfect either :-()

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gaetano Mendola 2005-02-17 01:56:54 Re: Help me recovering data
Previous Message Sergey E. Koposov 2005-02-16 23:53:16 Re: Strange RETURN NEXT behaviour in Postgres 8.0