diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2008-10-06 17:39:26 +0000 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2008-10-06 17:39:26 +0000 |
| commit | bf461538e18b67ec05d89846fcf15fa9c0cb9a74 (patch) | |
| tree | 7603c4ac7537ccf8e0afd51fb992d5d07c0631c5 /src/backend/utils/adt | |
| parent | e64bb65aff3f53b4f56b4a1ee549930b568cec99 (diff) | |
| download | postgresql-bf461538e18b67ec05d89846fcf15fa9c0cb9a74.tar.gz | |
When expanding a whole-row Var into a RowExpr during ResolveNew(), attach
the column alias names of the RTE referenced by the Var to the RowExpr.
This is needed to allow ruleutils.c to correctly deparse FieldSelect nodes
referencing such a construct. Per my recent bug report.
Adding a field to RowExpr forces initdb (because of stored rules changes)
so this solution is not back-patchable; which is unfortunate because 8.2
and 8.3 have this issue. But it only affects EXPLAIN for some pretty odd
corner cases, so we can probably live without a solution for the back
branches.
Diffstat (limited to 'src/backend/utils/adt')
| -rw-r--r-- | src/backend/utils/adt/ruleutils.c | 14 |
1 files changed, 13 insertions, 1 deletions
diff --git a/src/backend/utils/adt/ruleutils.c b/src/backend/utils/adt/ruleutils.c index fd21152b49..72b7e3c3d8 100644 --- a/src/backend/utils/adt/ruleutils.c +++ b/src/backend/utils/adt/ruleutils.c @@ -9,7 +9,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/utils/adt/ruleutils.c,v 1.285 2008/10/04 21:56:54 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/utils/adt/ruleutils.c,v 1.286 2008/10/06 17:39:26 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -3237,6 +3237,18 @@ get_name_for_var_field(Var *var, int fieldno, Node *expr; /* + * If it's a RowExpr that was expanded from a whole-row Var, use the + * column names attached to it. + */ + if (IsA(var, RowExpr)) + { + RowExpr *r = (RowExpr *) var; + + if (fieldno > 0 && fieldno <= list_length(r->colnames)) + return strVal(list_nth(r->colnames, fieldno - 1)); + } + + /* * If it's a Var of type RECORD, we have to find what the Var refers to; * if not, we can use get_expr_result_type. If that fails, we try * lookup_rowtype_tupdesc, which will probably fail too, but will ereport |