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
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)? |