From e5550fe9906664569694f92204d7186228e8f2ac Mon Sep 17 00:00:00 2001 From: naisila Date: Mon, 25 Jul 2022 22:35:52 +0300 Subject: [PATCH] Change comment regarding functions returning composite Relevant PG commit: c2fa113ddb1117b1f03e91960f65d5d7d8a90270 --- src/backend/distributed/deparser/ruleutils_15.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/backend/distributed/deparser/ruleutils_15.c b/src/backend/distributed/deparser/ruleutils_15.c index 1bc7d7166..642d27fa1 100644 --- a/src/backend/distributed/deparser/ruleutils_15.c +++ b/src/backend/distributed/deparser/ruleutils_15.c @@ -4037,9 +4037,9 @@ get_variable(Var *var, int levelsup, bool istoplevel, deparse_context *context) /* * If we find a Var referencing a dropped column, it seems better to * print something (anything) than to fail. In general this should - * not happen, but there are specific cases involving functions - * returning named composite types where we don't sufficiently enforce - * that you can't drop a column that's referenced in some view. + * not happen, but it used to be possible for some cases involving + * functions returning named composite types, and perhaps there are + * still bugs out there. */ if (attname == NULL) attname = "?dropped?column?";