提交 a9143774 编写于 作者: T Tom Lane

Expose the "*VALUES*" alias that we generate for a stand-alone VALUES list.

We were trying to make that strictly an internal implementation detail,
but it turns out that it's exposed anyway when dumping a view defined
like
	CREATE VIEW test_view AS VALUES (1), (2), (3) ORDER BY 1;
This comes out as
	CREATE VIEW ... ORDER BY "*VALUES*".column1;
which fails to parse when reloading the dump.

Hacking ruleutils.c to suppress the column qualification looks like it'd
be a risky business, so instead promote the RTE alias to full-fledged
usability.

Per bug #6049 from Dylan Adams.  Back-patch to all supported branches.
上级 04841751
......@@ -999,7 +999,7 @@ transformSelectStmt(ParseState *pstate, SelectStmt *stmt)
* transforms a VALUES clause that's being used as a standalone SELECT
*
* We build a Query containing a VALUES RTE, rather as if one had written
* SELECT * FROM (VALUES ...)
* SELECT * FROM (VALUES ...) AS "*VALUES*"
*/
static Query *
transformValuesClause(ParseState *pstate, SelectStmt *stmt)
......@@ -1162,6 +1162,7 @@ transformValuesClause(ParseState *pstate, SelectStmt *stmt)
rtr->rtindex = list_length(pstate->p_rtable);
Assert(rte == rt_fetch(rtr->rtindex, pstate->p_rtable));
pstate->p_joinlist = lappend(pstate->p_joinlist, rtr);
pstate->p_relnamespace = lappend(pstate->p_relnamespace, rte);
pstate->p_varnamespace = lappend(pstate->p_varnamespace, rte);
/*
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册