Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitff45274

Browse files
committed
Improve error message for rejecting RETURNING clauses with dropped columns.
This error message was written with only ON SELECT rules in mind, but sincethen we also made RETURNING-clause targetlists go through the same logic.This means that you got a rather off-topic error message if you tried toadd a rule with RETURNING to a table having dropped columns. Ideally we'djust support that, but some preliminary investigation says that it might bea significant amount of work. Seeing that Nicklas Avén's complaint is thefirst one we've gotten about this in the ten years or so that the code'sbeen like that, I'm unwilling to put much time into it. Instead, improvethe error report by issuing a different message for RETURNING cases, andrevise the associated comment based on this investigation.Discussion: 1456176604.17219.9.camel@jordogskog.no
1 parent4ef26ff commitff45274

File tree

1 file changed

+19
-7
lines changed

1 file changed

+19
-7
lines changed

‎src/backend/rewrite/rewriteDefine.c

Lines changed: 19 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -656,17 +656,29 @@ checkRuleResultList(List *targetList, TupleDesc resultDesc, bool isSelect,
656656
attname=NameStr(attr->attname);
657657

658658
/*
659-
* Disallow dropped columns in the relation. This won't happen in the
660-
* cases we actually care about (namely creating a view via CREATE
661-
* TABLE then CREATE RULE, or adding a RETURNING rule to a view).
662-
* Trying to cope with it is much more trouble than it's worth,
663-
* because we'd have to modify the rule to insert dummy NULLs at the
664-
* right positions.
659+
* Disallow dropped columns in the relation. This is not really
660+
* expected to happen when creating an ON SELECT rule. It'd be
661+
* possible if someone tried to convert a relation with dropped
662+
* columns to a view, but the only case we care about supporting
663+
* table-to-view conversion for is pg_dump, and pg_dump won't do that.
664+
*
665+
* Unfortunately, the situation is also possible when adding a rule
666+
* with RETURNING to a regular table, and rejecting that case is
667+
* altogether more annoying. In principle we could support it by
668+
* modifying the targetlist to include dummy NULL columns
669+
* corresponding to the dropped columns in the tupdesc. However,
670+
* places like ruleutils.c would have to be fixed to not process such
671+
* entries, and that would take an uncertain and possibly rather large
672+
* amount of work. (Note we could not dodge that by marking the dummy
673+
* columns resjunk, since it's precisely the non-resjunk tlist columns
674+
* that are expected to correspond to table columns.)
665675
*/
666676
if (attr->attisdropped)
667677
ereport(ERROR,
668678
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
669-
errmsg("cannot convert relation containing dropped columns to view")));
679+
isSelect ?
680+
errmsg("cannot convert relation containing dropped columns to view") :
681+
errmsg("cannot create a RETURNING list for a relation containing dropped columns")));
670682

671683
/* Check name match if required; no need for two error texts here */
672684
if (requireColumnNameMatch&&strcmp(tle->resname,attname)!=0)

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp