-
- Downloads
Fix check_srf_call_placement() to handle VALUES cases correctly.
INSERT ... VALUES with a single VALUES row is implemented quite differently from the general VALUES case. A user-visible implication of that is that we accept SRFs in the single-row case, but not in the multi-row case. That's a historical artifact no doubt, but in view of the lack of field complaints, I'm not excited about fixing it right now. However, check_srf_call_placement() needs to know about this, first because it should throw an error in the unsupported case, and second because it should set p_hasTargetSRFs in the single-row case (because we treat that like a SELECT tlist). That's an oversight in commit a4c35ea1. To fix, split EXPR_KIND_VALUES into two values. So far as I can see, this is the only place where we need to distinguish the two cases at present; but there might be more later. Patch by me, per report from Andres Freund. Discussion: https://postgr.es/m/20170116081548.zg63zltblwimpfgp@alap3.anarazel.de
Showing
- src/backend/parser/analyze.c 1 addition, 1 deletionsrc/backend/parser/analyze.c
- src/backend/parser/parse_agg.c 2 additions, 0 deletionssrc/backend/parser/parse_agg.c
- src/backend/parser/parse_expr.c 2 additions, 0 deletionssrc/backend/parser/parse_expr.c
- src/backend/parser/parse_func.c 6 additions, 1 deletionsrc/backend/parser/parse_func.c
- src/include/parser/parse_node.h 1 addition, 0 deletionssrc/include/parser/parse_node.h
- src/test/regress/expected/tsrf.out 3 additions, 1 deletionsrc/test/regress/expected/tsrf.out
Loading
Please register or sign in to comment