I looked into $SUBJECT, which complains about this:
CREATE VIEW test_view AS VALUES (1), (2), (3) ORDER BY 1;
This dumps like so:
regression=# \d+ test_view View "public.test_view"Column | Type | Modifiers | Storage | Description
---------+---------+-----------+---------+-------------column1 | integer | | plain |
View definition:VALUES (1), (2), (3) ORDER BY "*VALUES*".column1;
which is problematic because it'll fail during dump/restore, because
you can't write it that way:
regression=# VALUES (1), (2), (3) ORDER BY "*VALUES*".column1;
ERROR: invalid reference to FROM-clause entry for table "*VALUES*"
LINE 1: VALUES (1), (2), (3) ORDER BY "*VALUES*".column1; ^
HINT: There is an entry for table "*VALUES*", but it cannot be referenced from this part of the query.
The HINT gives a hint what's going on: we make an RTE for the VALUES
clause, and then we have to give it an alias, for which we use
"*VALUES*". But the code is trying to hide the existence of that
nonstandard alias by not exposing it in the parser's p_relnamespace
list. So you can write column1 to refer to the first result column
of the VALUES, but not "*VALUES*".column1.
On reflection this looks pretty stupid --- column1 is just as
nonstandard an alias, but we're allowing that to be used explicitly,
so why not the made-up table alias as well?
But anyway, there are basically two things we could do here: either
allow the table alias to be referenced, or try to teach ruleutils.c
not to qualify the column reference. The second looks pretty tricky
and maybe not future-proof, so I'm leaning to the first. Comments?
regards, tom lane