Skip site navigation (1) Skip section navigation (2)

Re: fix: plpgsql: return query and dropped columns problem

From: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Sergey Burladyan <eshkinkot(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Michael Tenenbaum <michael(at)strategic-techs(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: fix: plpgsql: return query and dropped columns problem
Date: 2009-07-20 06:58:56
Message-ID: 3073cc9b0907192358uacfb181r43949c79f51ae7cf@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
On Sun, Jul 12, 2009 at 10:28 AM, Pavel Stehule<pavel(dot)stehule(at)gmail(dot)com> wrote:
> Hello
>
> there is fix for bug Re: [BUGS] BUG #4907: stored procedures and changed tables
>

this one applies, compiles and it actually fixes the bug...
it should be backpatched until 8.3... but applies cleanly only until
8.4 (what a surprise), attached is an adapted version for 8.3

the only thing that is bothered me is that the same solution is used
again and again... seems like we can use a function like
make_tuple_from_row (maybe something like make_tuple_from_datum or
eliminate_dropped_cols_from_tuple or something like that) for avoiding
duplicate code... but that's another patch, is worth the trouble?

-- 
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

Attachment: return_query_fix-8.3.diff
Description: text/x-diff (2.8 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Jaime CasanovaDate: 2009-07-20 07:08:57
Subject: Re: Lock Wait Statistics (next commitfest)
Previous:From: Josh BerkusDate: 2009-07-20 06:30:36
Subject: Re: Review: Revise parallel pg_restore's scheduling heuristic

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-07-20 14:55:25
Subject: Re: fix: plpgsql: return query and dropped columns problem
Previous:From: Tom LaneDate: 2009-07-18 19:17:46
Subject: Re: bug or simply not enough stack space?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group