On 2016/08/04 18:03, Kouhei Kaigai wrote:
Also, the logic to print "Foreign (Scan|Insert|Update|Delete)" is different
from what I suggested. I'm suggesting to allow extension giving a label
to fill up "Foreign %s" format.
Please explain why your choice is better than my proposition.
No, I haven't done anything about that yet. I kept the behavior as-is.
At least, my proposition is available to apply on both of foreign-scan and
custom-scan, and no need to future maintenance if and when FDW gets support
remote Aggregation, Sort or others.
I'd like to discuss this issue separately, maybe in a new thread.
Why do you try to re-invent a similar infrastructure twice and separately?
As I said above, I haven't changed the behavior of EXPLAIN for *upper
relation processing* such as aggregation or sorting in a ForeignScan or
What I proposed perfectly covers what you want to do, and has more benefits.
- A common manner for both of ForeignScan and CustomScan
- Flexibility to control "Foreign XXX" label and relation names to be printed.
That may be so or not, but more importantly, this is more like a user
interface problem, so each person would have different opinions about that.
Even if it is sufficient for the current usage of FDW, I've been saying your
proposition is not sufficient for CustomScan nowadays, and ForeignScan in the
Again I haven't done anything about the EXPLAIN for upper relation
processing in both ForeignScan and CustomScan cases. I kept the
behavior as-is, but I don't think the behavior as-is is OK, either.
It is not an answer to ignore the CustomScan side, because we have to enhanced
the infrastructure of CustomScan side to follow up FDW sooner or later.
However, we will have to apply a different manner on CustomScan side, or
what you proposed on FDW side, at that time.
It is not a desirable future.
I agree on that point that it's better to handle both ForeignScan and
CustomScan cases the same way.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: