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

Commit2ed8f9a

Browse files
committed
Fix type-checking of RECORD-returning functions in FROM.
In the corner case where a function returning RECORD has beensimplified to a RECORD constant or an inlined ROW() expression,ExecInitFunctionScan failed to cross-check the function's resultrowtype against the coldeflist provided by the calling query.That happened because get_expr_result_type is able to extract atupdesc from such expressions, which led ExecInitFunctionScan toignore the coldeflist. (Instead, it used the extracted tupdescto check the function's output, which of course always succeeds.)I have not been able to demonstrate any really serious consequencesfrom this, because if some column of the result is of the wrongtype and is directly referenced by a Var of the calling query,CheckVarSlotCompatibility will catch it. However, we definitely dofail to report the case where the function returns more columns thanthe coldeflist expects, and in the converse case where it returnsfewer columns, we get an assert failure (but, seemingly, no worseresults in non-assert builds).To fix, always build the expected tupdesc from the coldeflist if thereis one, and consult get_expr_result_type only when there isn't one.Also remove the failing Assert, even though it is no longer reachedafter this fix. It doesn't seem to be adding anything useful, sincelater checking will deal with cases with the wrong number of columns.The only other place I could find that is doing something similaris inline_set_returning_function. There's no live bug there becausewe cannot be looking at a Const or RowExpr, but for consistencychange that code to agree with ExecInitFunctionScan.Per report from PetSerAl. After some debate I've concluded thatthis should be back-patched. There is a small risk that somebodyhas been relying on such a case not throwing an error, but I judgethis outweighed by the risk that I've missed some way in which thefailure to cross-check has worse consequences than sketched above.Discussion:https://postgr.es/m/CAKygsHSerA1eXsJHR9wft3Gn3wfHQ5RfP8XHBzF70_qcrrRvEg@mail.gmail.com
1 parentde7c6fe commit2ed8f9a

File tree

4 files changed

+76
-41
lines changed

4 files changed

+76
-41
lines changed

‎src/backend/executor/nodeFunctionscan.c

Lines changed: 45 additions & 36 deletions
Original file line numberDiff line numberDiff line change
@@ -343,8 +343,6 @@ ExecInitFunctionScan(FunctionScan *node, EState *estate, int eflags)
343343
Node*funcexpr=rtfunc->funcexpr;
344344
intcolcount=rtfunc->funccolcount;
345345
FunctionScanPerFuncState*fs=&scanstate->funcstates[i];
346-
TypeFuncClassfunctypclass;
347-
Oidfuncrettype;
348346
TupleDesctupdesc;
349347

350348
fs->setexpr=
@@ -361,39 +359,18 @@ ExecInitFunctionScan(FunctionScan *node, EState *estate, int eflags)
361359
fs->rowcount=-1;
362360

363361
/*
364-
* Now determine if the function returns a simple or composite type,
365-
* and build an appropriate tupdesc. Note that in the composite case,
366-
* the function may now return more columns than it did when the plan
367-
* was made; we have to ignore any columns beyond "colcount".
362+
* Now build a tupdesc showing the result type we expect from the
363+
* function. If we have a coldeflist then that takes priority (note
364+
* the parser enforces that there is one if the function's nominal
365+
* output type is RECORD). Otherwise use get_expr_result_type.
366+
*
367+
* Note that if the function returns a named composite type, that may
368+
* now contain more or different columns than it did when the plan was
369+
* made. For both that and the RECORD case, we need to check tuple
370+
* compatibility. ExecMakeTableFunctionResult handles some of this,
371+
* and CheckVarSlotCompatibility provides a backstop.
368372
*/
369-
functypclass=get_expr_result_type(funcexpr,
370-
&funcrettype,
371-
&tupdesc);
372-
373-
if (functypclass==TYPEFUNC_COMPOSITE||
374-
functypclass==TYPEFUNC_COMPOSITE_DOMAIN)
375-
{
376-
/* Composite data type, e.g. a table's row type */
377-
Assert(tupdesc);
378-
Assert(tupdesc->natts >=colcount);
379-
/* Must copy it out of typcache for safety */
380-
tupdesc=CreateTupleDescCopy(tupdesc);
381-
}
382-
elseif (functypclass==TYPEFUNC_SCALAR)
383-
{
384-
/* Base data type, i.e. scalar */
385-
tupdesc=CreateTemplateTupleDesc(1);
386-
TupleDescInitEntry(tupdesc,
387-
(AttrNumber)1,
388-
NULL,/* don't care about the name here */
389-
funcrettype,
390-
-1,
391-
0);
392-
TupleDescInitEntryCollation(tupdesc,
393-
(AttrNumber)1,
394-
exprCollation(funcexpr));
395-
}
396-
elseif (functypclass==TYPEFUNC_RECORD)
373+
if (rtfunc->funccolnames!=NIL)
397374
{
398375
tupdesc=BuildDescFromLists(rtfunc->funccolnames,
399376
rtfunc->funccoltypes,
@@ -409,8 +386,40 @@ ExecInitFunctionScan(FunctionScan *node, EState *estate, int eflags)
409386
}
410387
else
411388
{
412-
/* crummy error message, but parser should have caught this */
413-
elog(ERROR,"function in FROM has unsupported return type");
389+
TypeFuncClassfunctypclass;
390+
Oidfuncrettype;
391+
392+
functypclass=get_expr_result_type(funcexpr,
393+
&funcrettype,
394+
&tupdesc);
395+
396+
if (functypclass==TYPEFUNC_COMPOSITE||
397+
functypclass==TYPEFUNC_COMPOSITE_DOMAIN)
398+
{
399+
/* Composite data type, e.g. a table's row type */
400+
Assert(tupdesc);
401+
/* Must copy it out of typcache for safety */
402+
tupdesc=CreateTupleDescCopy(tupdesc);
403+
}
404+
elseif (functypclass==TYPEFUNC_SCALAR)
405+
{
406+
/* Base data type, i.e. scalar */
407+
tupdesc=CreateTemplateTupleDesc(1);
408+
TupleDescInitEntry(tupdesc,
409+
(AttrNumber)1,
410+
NULL,/* don't care about the name here */
411+
funcrettype,
412+
-1,
413+
0);
414+
TupleDescInitEntryCollation(tupdesc,
415+
(AttrNumber)1,
416+
exprCollation(funcexpr));
417+
}
418+
else
419+
{
420+
/* crummy error message, but parser should have caught this */
421+
elog(ERROR,"function in FROM has unsupported return type");
422+
}
414423
}
415424

416425
fs->tupdesc=tupdesc;

‎src/backend/optimizer/util/clauses.c

Lines changed: 9 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -5216,16 +5216,20 @@ inline_set_returning_function(PlannerInfo *root, RangeTblEntry *rte)
52165216
}
52175217

52185218
/*
5219-
* Also resolve the actual function result tupdesc, if composite. Ifthe
5220-
*function is just declared to return RECORD, dig the info out of the AS
5221-
*clause.
5219+
* Also resolve the actual function result tupdesc, if composite. Ifwe
5220+
*have a coldeflist, believe that; otherwise use get_expr_result_type.
5221+
*(This logic should match ExecInitFunctionScan.)
52225222
*/
5223-
functypclass=get_expr_result_type((Node*)fexpr,NULL,&rettupdesc);
5224-
if (functypclass==TYPEFUNC_RECORD)
5223+
if (rtfunc->funccolnames!=NIL)
5224+
{
5225+
functypclass=TYPEFUNC_RECORD;
52255226
rettupdesc=BuildDescFromLists(rtfunc->funccolnames,
52265227
rtfunc->funccoltypes,
52275228
rtfunc->funccoltypmods,
52285229
rtfunc->funccolcollations);
5230+
}
5231+
else
5232+
functypclass=get_expr_result_type((Node*)fexpr,NULL,&rettupdesc);
52295233

52305234
/*
52315235
* The single command must be a plain SELECT.

‎src/test/regress/expected/rangefuncs.out

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2485,3 +2485,16 @@ select * from
24852485
[{"id": "1"}] | 1
24862486
(1 row)
24872487

2488+
-- check detection of mismatching record types with a const-folded expression
2489+
with a(b) as (values (row(1,2,3)))
2490+
select * from a, coalesce(b) as c(d int, e int); -- fail
2491+
ERROR: function return row and query-specified return row do not match
2492+
DETAIL: Returned row contains 3 attributes, but query expects 2.
2493+
with a(b) as (values (row(1,2,3)))
2494+
select * from a, coalesce(b) as c(d int, e int, f int, g int); -- fail
2495+
ERROR: function return row and query-specified return row do not match
2496+
DETAIL: Returned row contains 3 attributes, but query expects 4.
2497+
with a(b) as (values (row(1,2,3)))
2498+
select * from a, coalesce(b) as c(d int, e int, f float); -- fail
2499+
ERROR: function return row and query-specified return row do not match
2500+
DETAIL: Returned type integer at ordinal position 3, but query expects double precision.

‎src/test/regress/sql/rangefuncs.sql

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -815,3 +815,12 @@ select * from
815815
from unnest(array['{"lectures": [{"id": "1"}]}'::jsonb])
816816
as unnested_modules(module))as ss,
817817
jsonb_to_recordset(ss.lecture)as j (idtext);
818+
819+
-- check detection of mismatching record types with a const-folded expression
820+
821+
with a(b)as (values (row(1,2,3)))
822+
select*from a, coalesce(b)as c(dint, eint);-- fail
823+
with a(b)as (values (row(1,2,3)))
824+
select*from a, coalesce(b)as c(dint, eint, fint, gint);-- fail
825+
with a(b)as (values (row(1,2,3)))
826+
select*from a, coalesce(b)as c(dint, eint, f float);-- fail

0 commit comments

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