Re: oversight in EphemeralNamedRelation support
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>,
PG Hackers <pgsql-hackers@postgresql.org>,
Hugo Mercier <hugo.mercier@oslandia.com>,
Kevin Grittner <kgrittn@gmail.com>
Date: 2017-10-12T19:50:51Z
Lists: pgsql-hackers
Julien Rouhaud <rjuju123@gmail.com> writes: > On Mon, Oct 9, 2017 at 10:43 PM, Thomas Munro > <thomas.munro@enterprisedb.com> wrote: >> I suppose we could consider moving the schemaname check into >> getRTEForSpecialRelationType(), since otherwise both callers need to >> do that (and as you discovered, one forgot). > Thanks for the feedback. That was my first idea, but I assumed there > could be future use for this function on qualified RangeVar if it > wasn't done this way. > I agree it'd be much safer, so v2 attached, check moved in > getRTEForSpecialRelationType(). Hm. I actually think the bug here is that 18ce3a4ab introduced anything into setTargetTable at all. There was never previously any assumption that the target could be anything but a regular table, so we just ignored CTEs there, and I do not think the new behavior is an improvement. So my proposal is to rip out the getRTEForSpecialRelationTypes check there. I tend to agree that getRTEForSpecialRelationTypes should probably contain an explicit check for unqualified name rather than relying on its caller ... but that's a matter of future-proofing not a bug fix. regards, tom lane
Commits
-
Fix incorrect handling of CTEs and ENRs as DML target relations.
- 7421f4b89a90 11.0 landed
- 799037099b4f 10.1 landed