Etsuro Fujita writes:
> On Tue, Dec 3, 2019 at 6:45 AM Tom Lane wrote:
>> Concretely, I'm thinking of the attached (on top of the other patch,
>> which I just pushed). This agrees exactly with what ExplainTargetRel
>> does for regular scans.
> Thanks for the patch! (The patch didn't apply to H
On Tue, Dec 3, 2019 at 6:45 AM Tom Lane wrote:
> I wrote:
> > Etsuro Fujita writes:
> >> On Mon, Dec 2, 2019 at 6:34 AM Tom Lane wrote:
> >>> BTW, the existing code always schema-qualifies the relation names,
> >>> on the rather lame grounds that it's producing the string without
> >>> knowing w
I wrote:
> Etsuro Fujita writes:
>> On Mon, Dec 2, 2019 at 6:34 AM Tom Lane wrote:
>>> BTW, the existing code always schema-qualifies the relation names,
>>> on the rather lame grounds that it's producing the string without
>>> knowing whether EXPLAIN VERBOSE will be specified. In this code,
>>>
Etsuro Fujita writes:
> I think "names of relation" should be "names of relations", so how
> about fixing that as well?
Ah, missed that.
> On Mon, Dec 2, 2019 at 6:34 AM Tom Lane wrote:
>> BTW, the existing code always schema-qualifies the relation names,
>> on the rather lame grounds that it's
On Mon, Dec 2, 2019 at 6:34 AM Tom Lane wrote:
> I wrote:
> > 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
On Sun, Dec 1, 2019 at 11:40 AM Tom Lane wrote:
> then the EXPLAIN output produced by HEAD looks like:
>
> QUERY PLAN
> ---
> Sort
>Output: p.x, p.b
>Sort Key: p.x
>-> Append
> -> Seq Scan on public.part_p1 p
>
I wrote:
> 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
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 ag
