Re: BUG #14799: SELECT * FROM transition_table in a statement-level trigger

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: phb07(at)apra(dot)asso(dot)fr, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>, Kevin Grittner <kgrittn(at)postgresql(dot)org>
Subject: Re: BUG #14799: SELECT * FROM transition_table in a statement-level trigger
Date: 2017-09-06 21:20:02
Message-ID: CAEepm=2cdVgk1xnRi7pwxY=NLJbFvfrxsQKscGo+W8EU3Fi3mw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Sep 7, 2017 at 1:32 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> phb07(at)apra(dot)asso(dot)fr writes:
>> I am playing a bit with transition tables in statement-level triggers, using
>> the postgres V10 beta 4 version. I am facing an issue that I suspect to be a
>> bug (unless it is a design limitation). I have built a small test case to
>> reproduce what I have discovered.
>> ...
>> It looks like the resolution of the column list has not taken into account a
>> "NOT attisdropped" condition when scanning the pg_attribute table (or an
>> equivalent in memory structure).
>
> Yeah. The RTE_NAMEDTUPLESTORE patch seems to have piggybacked on the code
> for RTE_CTE and friends, none of which could have dropped columns so the
> case wasn't considered. I think the immediate problem is in expandRTE()
> but I have zero faith that there aren't comparable bugs elsewhere.

Ouch. Thanks for fixing this bug, which I would have picked up if I'd
been awake at the time.

--
Thomas Munro
http://www.enterprisedb.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2017-09-06 21:22:37 Re: BUG #14799: SELECT * FROM transition_table in a statement-level trigger
Previous Message Andres Freund 2017-09-06 19:23:53 Re: [BUGS] Bug in Physical Replication Slots (at least 9.5)?