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

Commit9a8aa25

Browse files
committed
Fix misidentification of SQL statement type in plpgsql's exec_stmt_execsql.
To distinguish SQL statements that are INSERT/UPDATE/DELETE from otherones, exec_stmt_execsql looked at the post-rewrite form of the statementrather than the original. This is problematic because it did that onlyduring first execution of the statement (in a session), but the correctanswer could change later due to addition or removal of DO INSTEAD rulesduring the session. That could lead to an Assert failure, as reportedby Tushar Ahuja and Robert Haas. In non-assert builds, there's a hazardthat we would fail to enforce STRICT behavior when we'd be expected to.That would happen if an initially present DO INSTEAD, that replaced theoriginal statement with one of a different type, were removed; after thatthe statement should act "normally", including strictness enforcement, butit didn't. (The converse case of enforcing strictness when we shouldn'tdoesn't seem to be a hazard, as addition of a DO INSTEAD that changes thestatement type would always lead to acting as though the statement returnedzero rows, so that the strictness error could not fire.)To fix, inspect the original form of the statement not the post-rewriteform, making it valid to assume the answer can't change intra-session.This should lead to the same answer in every case except when there is aDO INSTEAD that changes the statement type; we will now set mod_stmt=trueanyway, while we would not have done so before. That breaks the Assertin the SPI_OK_REWRITTEN code path, which expected the latter behavior.It might be all right to assert mod_stmt rather than !mod_stmt there,but I'm not entirely convinced that that'd always hold, so just removethe assertion altogether.This has been broken for a long time, so back-patch to all supportedbranches.Discussion:https://postgr.es/m/CA+TgmoZUrRN4xvZe_BbBn_Xp0BDwuMEue-0OyF0fJpfvU2Yc7Q@mail.gmail.com
1 parent7019c21 commit9a8aa25

File tree

1 file changed

+14
-13
lines changed

1 file changed

+14
-13
lines changed

‎src/pl/plpgsql/src/pl_exec.c

Lines changed: 14 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -4031,19 +4031,20 @@ exec_stmt_execsql(PLpgSQL_execstate *estate,
40314031
foreach(l,SPI_plan_get_plan_sources(expr->plan))
40324032
{
40334033
CachedPlanSource*plansource= (CachedPlanSource*)lfirst(l);
4034-
ListCell*l2;
40354034

4036-
foreach(l2,plansource->query_list)
4035+
/*
4036+
* We could look at the raw_parse_tree, but it seems simpler to
4037+
* check the command tag. Note we should *not* look at the Query
4038+
* tree(s), since those are the result of rewriting and could have
4039+
* been transmogrified into something else entirely.
4040+
*/
4041+
if (plansource->commandTag&&
4042+
(strcmp(plansource->commandTag,"INSERT")==0||
4043+
strcmp(plansource->commandTag,"UPDATE")==0||
4044+
strcmp(plansource->commandTag,"DELETE")==0))
40374045
{
4038-
Query*q=lfirst_node(Query,l2);
4039-
4040-
if (q->canSetTag)
4041-
{
4042-
if (q->commandType==CMD_INSERT||
4043-
q->commandType==CMD_UPDATE||
4044-
q->commandType==CMD_DELETE)
4045-
stmt->mod_stmt= true;
4046-
}
4046+
stmt->mod_stmt= true;
4047+
break;
40474048
}
40484049
}
40494050
}
@@ -4108,12 +4109,12 @@ exec_stmt_execsql(PLpgSQL_execstate *estate,
41084109
break;
41094110

41104111
caseSPI_OK_REWRITTEN:
4111-
Assert(!stmt->mod_stmt);
41124112

41134113
/*
41144114
* The command was rewritten into another kind of command. It's
41154115
* not clear what FOUND would mean in that case (and SPI doesn't
4116-
* return the row count either), so just set it to false.
4116+
* return the row count either), so just set it to false. Note
4117+
* that we can't assert anything about mod_stmt here.
41174118
*/
41184119
exec_set_found(estate, false);
41194120
break;

0 commit comments

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