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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers