Re: autogenerated column names + views are a dump hazard

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> Hm, so I looked into it, and I think the problem is actually restricted
> to columns where the typename that FigureColname() assigns is different
> from the one that will result after ger_rule_expr()/get_const_expr()'s
> implicit cast is added.

> For this case it seems easiest if we'd make get_rule_expr() (and some of
> its helpers) return whether an implicit cast has been added.

Aside from being pretty ugly, that doesn't seem particularly bulletproof.
It might deal all right with this specific manifestation, but now that
we've seen the problem, who's to say that there aren't other ways to get
bit? Or that some innocent future change to FigureColname() might not
create a new one? It's not like the behavior of that function was handed
down on stone tablets --- we do change it from time to time.

I wondered whether there was a way to directly test whether
FigureColname() gives a different result from what we have recorded
as the effective column name. Unfortunately, it wants a raw parse tree
whereas what we have is an analyzed parse tree, so there's no easy way
to apply it and see.

Now, we do have the deparsed text of the column expression at hand,
so in principle you could run that back through the grammar to get a raw
parse tree, and then apply FigureColname() to that. Not sure what that
would be like from a performance standpoint, but it would provide a pretty
robust fix for this class of problem.

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.

Or we could consider printing them always if the "pretty" flag isn't
on. IIRC, pg_dump doesn't enable that.

regards, tom lane