From: | "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Richard Huxton <dev(at)archonet(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Strange RETURN NEXT behaviour in Postgres 8.0 |
Date: | 2005-02-17 20:57:53 |
Message-ID: | Pine.LNX.4.44.0502171203140.7439-100000@lnfm1.sai.msu.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 16 Feb 2005, Tom Lane wrote:
> 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.
>
> 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 :-()
Finally I want to clarify, that after copying my "usno" table into another,
the problems have disappeared.
So I had experienced just exacty the bug with dropped columns.
So, is there a chance that this bug will be fixed in some 8.X postgres ?
Sergey
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2005-02-17 22:14:24 | Re: win32 performance - fsync question |
Previous Message | Merlin Moncure | 2005-02-17 20:39:38 | Re: win32 performance - fsync question |