Shigeru Hanada <shigeru.hanada@gmail.com> writes:
> So, just renaming create_foreignscan_path to plural form seems missing
> the point.
I agree that that wouldn't be an improvement. What bothers me about the
patch's version of this function is that it just creates a content-free
Path node and leaves it to the caller to fill in everything. That
doesn't accomplish much, and it leaves the caller very exposed to errors
of omission. It's also unlike the other create_xxx_path functions,
which generally hand back a completed Path ready to pass to add_path.
I'm inclined to think that if we provide this function in core at all,
it should take a parameter list long enough to let it fill in the Path
completely. That would imply that any future changes in Path structs
would result in a change in the parameter list, which would break
callers --- but it would break them in an obvious way that the C
compiler would complain about. If we leave it as-is, those same callers
would be broken silently, because they'd just be failing to fill in
the new Path fields.
regards, tom lane