pgsql: Fix check_srf_call_placement() to handle VALUES cases correctly.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Fix check_srf_call_placement() to handle VALUES cases correctly.
Date: 2017-01-16 20:23:20
Message-ID: E1cTDoG-0002ko-V2@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

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 a4c35ea1c.

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

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/d43a619c60405ecda275ca9e3ac9ead242e20ecb

Modified Files
--------------
src/backend/parser/analyze.c | 2 +-
src/backend/parser/parse_agg.c | 2 ++
src/backend/parser/parse_expr.c | 2 ++
src/backend/parser/parse_func.c | 7 ++++++-
src/include/parser/parse_node.h | 1 +
src/test/regress/expected/tsrf.out | 4 +++-
6 files changed, 15 insertions(+), 3 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2017-01-16 22:48:42 Re: [COMMITTERS] pgsql: Permit dump/reload of not-too-large >1GB tuples
Previous Message Tom Lane 2017-01-16 18:53:46 pgsql: Fix NULL pointer dereference in tuplesort.c.