Re: autogenerated column names + views are a dump hazard
От | Tom Lane |
---|---|
Тема | Re: autogenerated column names + views are a dump hazard |
Дата | |
Msg-id | 10455.1425398969@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: autogenerated column names + views are a dump hazard (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: autogenerated column names + views are a dump hazard
|
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> writes: > On 2015-03-03 09:39:03 -0500, Tom Lane wrote: >> And on the third hand ... doing that would really only be robust as long >> as you assume that the output will be read by a server using exactly the >> same FigureColname() logic as what we are using. So maybe the whole idea >> is a bad one, and we should just bite the bullet and print AS clauses >> always. > I think this is the way to go though. There's different extremes we can > go to though - the easiest is to simply remove the attname = "?column?" > assignment from get_target_list(). That way plain Var references (aside > from whole row vars/subplans and such that get_variable() deals with) > don't get a forced alias, but everything else does. That seems like a > good compromise between readability and safety. get_rule_expr() deals > with most of the "nasty" stuff. I wasn't aware that there was any room for "compromise" on the safety aspect. If pg_dump gets this wrong, that means pg_upgrade is broken, for example. That's why I was thinking that relying on the pretty flag might be a reasonable thing. pg_dump would be unconditionally right, and we'd not uglify EXPLAIN or \d+ output. regards, tom lane
В списке pgsql-hackers по дате отправления: