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

Commitec62cb0

Browse files
committed
Revert applying column aliases to the output of whole-row Vars.
In commitbf7ca15, I had the bright idea that we could make theresult of a whole-row Var (that is, foo.*) track any column aliasesthat had been applied to the FROM entry the Var refers to. However,that's not terribly logically consistent, because now the output ofthe Var is no longer of the named composite type that the Var claimsto emit.bf7ca15 tried to handle that by changing the outputtuple values to be labeled with a blessed RECORD type, but that'sreally pretty disastrous: we can wind up storing such tuples ontodisk, whereupon they're not readable by other sessions.The only practical fix I can see is to give up on whatbf7ca15tried to do, and say that the column names of tuples produced bya whole-row Var are always those of the underlying named compositetype, query aliases or no. While this introduces some inconsistencies,it removes others, so it's not that awful in the abstract. What *is*kind of awful is to make such a behavioral change in a back-patchedbug fix. But corrupt data is worse, so back-patched it will be.(A workaround available to anyone who's unhappy about this is tointroduce an extra level of sub-SELECT, so that the whole-row Var isreferring to the sub-SELECT's output and not to a named table type.Then the Var is of type RECORD to begin with and there's no issue.)Per report from Miles Delahunty. The faulty commit dates to 9.5,so back-patch to all supported branches.Discussion:https://postgr.es/m/2950001.1638729947@sss.pgh.pa.us
1 parent39f0c4b commitec62cb0

File tree

5 files changed

+54
-92
lines changed

5 files changed

+54
-92
lines changed

‎src/backend/executor/execExpr.c

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1913,16 +1913,16 @@ ExecInitExprRec(Expr *node, ExprState *state,
19131913
{
19141914
/* generic record, use types of given expressions */
19151915
tupdesc=ExecTypeFromExprList(rowexpr->args);
1916+
/* ... but adopt RowExpr's column aliases */
1917+
ExecTypeSetColNames(tupdesc,rowexpr->colnames);
1918+
/* Bless the tupdesc so it can be looked up later */
1919+
BlessTupleDesc(tupdesc);
19161920
}
19171921
else
19181922
{
19191923
/* it's been cast to a named type, use that */
19201924
tupdesc=lookup_rowtype_tupdesc_copy(rowexpr->row_typeid,-1);
19211925
}
1922-
/* In either case, adopt RowExpr's column aliases */
1923-
ExecTypeSetColNames(tupdesc,rowexpr->colnames);
1924-
/* Bless the tupdesc in case it's now of type RECORD */
1925-
BlessTupleDesc(tupdesc);
19261926

19271927
/*
19281928
* In the named-type case, the tupdesc could have more columns

‎src/backend/executor/execExprInterp.c

Lines changed: 33 additions & 39 deletions
Original file line numberDiff line numberDiff line change
@@ -4021,12 +4021,8 @@ ExecEvalWholeRowVar(ExprState *state, ExprEvalStep *op, ExprContext *econtext)
40214021
* generates an INT4 NULL regardless of the dropped column type).
40224022
* If we find a dropped column and cannot verify that case (1)
40234023
* holds, we have to use the slow path to check (2) for each row.
4024-
*
4025-
* If vartype is a domain over composite, just look through that
4026-
* to the base composite type.
40274024
*/
4028-
var_tupdesc=lookup_rowtype_tupdesc_domain(variable->vartype,
4029-
-1, false);
4025+
var_tupdesc=lookup_rowtype_tupdesc(variable->vartype,-1);
40304026

40314027
slot_tupdesc=slot->tts_tupleDescriptor;
40324028

@@ -4063,9 +4059,8 @@ ExecEvalWholeRowVar(ExprState *state, ExprEvalStep *op, ExprContext *econtext)
40634059

40644060
/*
40654061
* Use the variable's declared rowtype as the descriptor for the
4066-
* output values, modulo possibly assigning new column names
4067-
* below. In particular, we *must* absorb any attisdropped
4068-
* markings.
4062+
* output values. In particular, we *must* absorb any
4063+
* attisdropped markings.
40694064
*/
40704065
oldcontext=MemoryContextSwitchTo(econtext->ecxt_per_query_memory);
40714066
output_tupdesc=CreateTupleDescCopy(var_tupdesc);
@@ -4083,39 +4078,38 @@ ExecEvalWholeRowVar(ExprState *state, ExprEvalStep *op, ExprContext *econtext)
40834078
oldcontext=MemoryContextSwitchTo(econtext->ecxt_per_query_memory);
40844079
output_tupdesc=CreateTupleDescCopy(slot->tts_tupleDescriptor);
40854080
MemoryContextSwitchTo(oldcontext);
4086-
}
40874081

4088-
/*
4089-
* Construct a tuple descriptor for the composite values we'll
4090-
* produce, and make sure its record type is "blessed". The main
4091-
* reason to do this is to be sure that operations such as
4092-
* row_to_json() will see the desired column names when they look up
4093-
* the descriptor from the type information embedded in the composite
4094-
* values.
4095-
*
4096-
* We already got the correct physical datatype info above, but now we
4097-
* should try to find the source RTE and adopt its column aliases, in
4098-
* case they are different from the original rowtype's names. For
4099-
* example, in "SELECT foo(t) FROM tab t(x,y)", the first two columns
4100-
* in the composite output should be named "x" and "y" regardless of
4101-
* tab's column names.
4102-
*
4103-
* If we can't locate the RTE, assume the column names we've got are
4104-
* OK. (As of this writing, the only cases where we can't locate the
4105-
* RTE are in execution of trigger WHEN clauses, and then the Var will
4106-
* have the trigger's relation's rowtype, so its names are fine.)
4107-
* Also, if the creator of the RTE didn't bother to fill in an eref
4108-
* field, assume our column names are OK. (This happens in COPY, and
4109-
* perhaps other places.)
4110-
*/
4111-
if (econtext->ecxt_estate&&
4112-
variable->varno <=econtext->ecxt_estate->es_range_table_size)
4113-
{
4114-
RangeTblEntry*rte=exec_rt_fetch(variable->varno,
4115-
econtext->ecxt_estate);
4082+
/*
4083+
* It's possible that the input slot is a relation scan slot and
4084+
* so is marked with that relation's rowtype. But we're supposed
4085+
* to be returning RECORD, so reset to that.
4086+
*/
4087+
output_tupdesc->tdtypeid=RECORDOID;
4088+
output_tupdesc->tdtypmod=-1;
41164089

4117-
if (rte->eref)
4118-
ExecTypeSetColNames(output_tupdesc,rte->eref->colnames);
4090+
/*
4091+
* We already got the correct physical datatype info above, but
4092+
* now we should try to find the source RTE and adopt its column
4093+
* aliases, since it's unlikely that the input slot has the
4094+
* desired names.
4095+
*
4096+
* If we can't locate the RTE, assume the column names we've got
4097+
* are OK. (As of this writing, the only cases where we can't
4098+
* locate the RTE are in execution of trigger WHEN clauses, and
4099+
* then the Var will have the trigger's relation's rowtype, so its
4100+
* names are fine.) Also, if the creator of the RTE didn't bother
4101+
* to fill in an eref field, assume our column names are OK. (This
4102+
* happens in COPY, and perhaps other places.)
4103+
*/
4104+
if (econtext->ecxt_estate&&
4105+
variable->varno <=econtext->ecxt_estate->es_range_table_size)
4106+
{
4107+
RangeTblEntry*rte=exec_rt_fetch(variable->varno,
4108+
econtext->ecxt_estate);
4109+
4110+
if (rte->eref)
4111+
ExecTypeSetColNames(output_tupdesc,rte->eref->colnames);
4112+
}
41194113
}
41204114

41214115
/* Bless the tupdesc if needed, and save it in the execution state */

‎src/backend/executor/execTuples.c

Lines changed: 13 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -2022,51 +2022,40 @@ ExecTypeFromExprList(List *exprList)
20222022
}
20232023

20242024
/*
2025-
* ExecTypeSetColNames - set column names in a TupleDesc
2025+
* ExecTypeSetColNames - set column names in aRECORDTupleDesc
20262026
*
20272027
* Column names must be provided as an alias list (list of String nodes).
2028-
*
2029-
* For some callers, the supplied tupdesc has a named rowtype (not RECORD)
2030-
* and it is moderately likely that the alias list matches the column names
2031-
* already present in the tupdesc. If we do change any column names then
2032-
* we must reset the tupdesc's type to anonymous RECORD; but we avoid doing
2033-
* so if no names change.
20342028
*/
20352029
void
20362030
ExecTypeSetColNames(TupleDesctypeInfo,List*namesList)
20372031
{
2038-
boolmodified= false;
20392032
intcolno=0;
20402033
ListCell*lc;
20412034

2035+
/* It's only OK to change col names in a not-yet-blessed RECORD type */
2036+
Assert(typeInfo->tdtypeid==RECORDOID);
2037+
Assert(typeInfo->tdtypmod<0);
2038+
20422039
foreach(lc,namesList)
20432040
{
20442041
char*cname=strVal(lfirst(lc));
20452042
Form_pg_attributeattr;
20462043

2047-
/* Guard against too-long names list */
2044+
/* Guard against too-long names list(probably can't happen)*/
20482045
if (colno >=typeInfo->natts)
20492046
break;
20502047
attr=TupleDescAttr(typeInfo,colno);
20512048
colno++;
20522049

2053-
/* Ignore empty aliases (these must be for dropped columns) */
2054-
if (cname[0]=='\0')
2050+
/*
2051+
* Do nothing for empty aliases or dropped columns (these cases
2052+
* probably can't arise in RECORD types, either)
2053+
*/
2054+
if (cname[0]=='\0'||attr->attisdropped)
20552055
continue;
20562056

2057-
/* Change tupdesc only if alias is actually different */
2058-
if (strcmp(cname,NameStr(attr->attname))!=0)
2059-
{
2060-
namestrcpy(&(attr->attname),cname);
2061-
modified= true;
2062-
}
2063-
}
2064-
2065-
/* If we modified the tupdesc, it's now a new record type */
2066-
if (modified)
2067-
{
2068-
typeInfo->tdtypeid=RECORDOID;
2069-
typeInfo->tdtypmod=-1;
2057+
/* OK, assign the column name */
2058+
namestrcpy(&(attr->attname),cname);
20702059
}
20712060
}
20722061

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

Lines changed: 2 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -1010,18 +1010,8 @@ select row_to_json(i) from int8_tbl i;
10101010
{"q1":4567890123456789,"q2":-4567890123456789}
10111011
(5 rows)
10121012

1013+
-- since "i" is of type "int8_tbl", attaching aliases doesn't change anything:
10131014
select row_to_json(i) from int8_tbl i(x,y);
1014-
row_to_json
1015-
----------------------------------------------
1016-
{"x":123,"y":456}
1017-
{"x":123,"y":4567890123456789}
1018-
{"x":4567890123456789,"y":123}
1019-
{"x":4567890123456789,"y":4567890123456789}
1020-
{"x":4567890123456789,"y":-4567890123456789}
1021-
(5 rows)
1022-
1023-
create temp view vv1 as select * from int8_tbl;
1024-
select row_to_json(i) from vv1 i;
10251015
row_to_json
10261016
------------------------------------------------
10271017
{"q1":123,"q2":456}
@@ -1031,16 +1021,7 @@ select row_to_json(i) from vv1 i;
10311021
{"q1":4567890123456789,"q2":-4567890123456789}
10321022
(5 rows)
10331023

1034-
select row_to_json(i) from vv1 i(x,y);
1035-
row_to_json
1036-
----------------------------------------------
1037-
{"x":123,"y":456}
1038-
{"x":123,"y":4567890123456789}
1039-
{"x":4567890123456789,"y":123}
1040-
{"x":4567890123456789,"y":4567890123456789}
1041-
{"x":4567890123456789,"y":-4567890123456789}
1042-
(5 rows)
1043-
1024+
-- in these examples, we'll report the exposed column names of the subselect:
10441025
select row_to_json(ss) from
10451026
(select q1, q2 from int8_tbl) as ss;
10461027
row_to_json

‎src/test/regress/sql/rowtypes.sql

Lines changed: 2 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -417,12 +417,10 @@ select longname(f) from fullname f;
417417
--
418418

419419
select row_to_json(i)from int8_tbl i;
420+
-- since "i" is of type "int8_tbl", attaching aliases doesn't change anything:
420421
select row_to_json(i)from int8_tbl i(x,y);
421422

422-
create temp view vv1asselect*from int8_tbl;
423-
select row_to_json(i)from vv1 i;
424-
select row_to_json(i)from vv1 i(x,y);
425-
423+
-- in these examples, we'll report the exposed column names of the subselect:
426424
select row_to_json(ss)from
427425
(select q1, q2from int8_tbl)as ss;
428426
select row_to_json(ss)from

0 commit comments

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