On Mon, Jun 13, 2016 at 5:51 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Jun 10, 2016 at 4:14 PM, Robert Haas <robertmh...@gmail.com> wrote: >> Although I have done a bit of review of this patch, it needs more >> thought than I have so far had time to give it. I will update again >> by Tuesday. > > I've reviewed this a bit further and have discovered an infelicity.
Also, independent of the fix for this particular issue, I think it would be smart to apply the attached patch to promote the assertion that failed here to an elog(). If we have more bugs of this sort, now or in the future, I'd like to catch them even in non-assert-enabled builds by getting a sensible error rather than just by failing an assertion. I think it's our general practice to check node types with elog() rather than Assert() when the nodes are coming from some far-distant part of the code, which is certainly the case here. I plan to commit this without delay unless there are vigorous, well-reasoned objections. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
diff --git a/contrib/postgres_fdw/deparse.c b/contrib/postgres_fdw/deparse.c index 7d2512c..f38da5d 100644 --- a/contrib/postgres_fdw/deparse.c +++ b/contrib/postgres_fdw/deparse.c @@ -1112,8 +1112,10 @@ deparseExplicitTargetList(List *tlist, List **retrieved_attrs, /* Extract expression if TargetEntry node */ Assert(IsA(tle, TargetEntry)); var = (Var *) tle->expr; + /* We expect only Var nodes here */ - Assert(IsA(var, Var)); + if (!IsA(var, Var)) + elog(ERROR, "non-Var not expected in target list"); if (i > 0) appendStringInfoString(buf, ", ");
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
