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

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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Sergey Burladyan <eshkinkot(at)gmail(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-30 18:45:30
Message-ID: 162867790907301145y65436a80pe533ff2fa1b8c302@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
2009/7/30 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> writes:
>>> On Mon, Jul 20, 2009 at 10:09 AM, Alvaro
>>>> Getting rid of the check on natts was "ungood" ... it needs to compare
>>>> the number of undropped columns of both tupdescs.
>
>> patch attached
>
> This patch is *still* introducing more bugs than it fixes.  The reason
> is that it has modified validate_tupdesc_compat to allow the tupdescs to
> be somewhat different, but has fixed only one of the several call sites
> to deal with the consequences of that.  The others will now become crash
> risks if we apply it as-is.
>
> What I would suggest as a suitable plan for a fix is to modify
> validate_tupdesc_compat so that it returns a flag indicating whether the
> tupdesc compatibility is exact or requires translation.  If translation
> is required, provide another routine that does that --- probably using a
> mapping data structure set up by validate_tupdesc_compat, since in some
> of these cases we'll be processing many tuples.  Then the callers just
> have to know enough to call the tuple-translation function when
> validate_tupdesc_compat tells them to.
>

ook I'll to try modify patch in this direction.

Pavel
> There are a number of other places in the system with similar
> requirements, although none of them seem to be exact matches.
> In particular ExecEvalConvertRowtype() provides a good template for
> efficient translation logic, but it's using column name matching
> rather than positional matching so you couldn't share the setup logic.
> I'm not sure if it's worth moving all this code into the core so that
> it can be shared with other future uses (maybe in other PLs), but it's
> worth considering that.  access/common/heaptuple.c or tupdesc.c might
> be a good place for it if we decide to do that.
>
> The executor's junkfilter code is pretty nearly related as well, and
> perhaps the Right Thing is to make all of this stuff into applications
> of junkfilters with different setup routines for the different
> requirements.  However the junkfilter code is designed to work with
> tuples that are in TupleTableSlots, which isn't particularly helpful for
> plpgsql's uses, so maybe trying to unify with that code is more trouble
> than it's worth.
>
> I'm marking this patch as Waiting on Author again, although perhaps
> Returned with Feedback would be better since my suggestions amount
> to wholesale rewrites.
>
>                        regards, tom lane
>

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-07-30 20:03:26
Subject: Re: improvements for dict_xsyn extended synonym dictionary - RRR
Previous:From: Tom LaneDate: 2009-07-30 18:31:31
Subject: Re: fix: plpgsql: return query and dropped columns problem

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-07-30 21:34:48
Subject: Re: BUG #4945: Parallel update(s) gone wild
Previous:From: Giorgio ValotiDate: 2009-07-30 18:36:18
Subject: Fwd: BUG #4953: Crash with xml functions

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