Shigeru Hanada <shigeru.han...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers