Re: pgsql_fdw, FDW for PostgreSQL server

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>
Cc: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql_fdw, FDW for PostgreSQL server
Date: 2012-03-05 17:58:11
Message-ID: 23125.1330970291@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-03-05 17:59:49 Re: Patch review for logging hooks (CF 2012-01)
Previous Message Robert Haas 2012-03-05 17:57:44 Re: poll: CHECK TRIGGER?