From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | kathy(dot)forte(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: autogenerated column names + views are a dump hazard |
Date: | 2015-03-03 16:09:29 |
Message-ID: | 10455.1425398969@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2015-03-03 16:11:22 | Re: New CF app deployment |
Previous Message | Bruce Momjian | 2015-03-03 15:58:28 | Re: New CF app deployment |