Re: Bogus EXPLAIN results with column aliases for mismatched partitions

I wrote:
> * variant-a's diffs in expected/postgres_fdw.out indicate that
> postgres_fdw is doing something weird with the table aliases it selects to
> print in the "Relations:" output.  I think this is an independent bug ---
> and it surely *is* a bug, because the aliases printed by HEAD don't agree
> with the table aliases used for Vars of those relations.  But I haven't
> run it to ground yet.  (Notice that variant-b fixes those discrepancies in
> the opposite direction...)

I checked that, and indeed postgres_fdw is doing something randomly
different from what ruleutils does.  In set_rtable_names(), the
first priority is rte->alias->aliasname, and if that's not set
then (for a RELATION RTE) you get the result of get_rel_name().
postgres_fdw is taking rte->eref->aliasname as being the alias,
which is usually the same string, but "usually" doesn't cut it.
So we should make it look at rte->alias instead.

Now, there is another thing that set_rtable_names() is doing that
postgres_fdw doesn't do, which is to unique-ify the chosen alias
names by adding "_NN" if the querytree contains multiple uses of
the same table alias.  I don't see any practical way for postgres_fdw
to match that behavior, since it lacks global information about the
query.  If we wanted to fix it, what we'd likely need to do is
postpone creation of the relation_name strings until EXPLAIN,
providing some way for postgres_fdw to ask ruleutils.c what alias
it'd assigned to a particular RTE.  This seems like it wouldn't be
terribly painful for base relations but it'd be a mess for joins
and aggregates, so I'm not eager to do something like that.
In practice the presence or absence of "_NN" might not be too
confusing --- it's certainly not as bad as the inconsistency being
shown now.

In short then I propose the attached fix for this issue.

			regards, tom lane