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