Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> I needed something to test the FDW API patch with, and didn't want to
> get involved in the COPY API changes, and also wanted to have something
> that needs real connection management and can push down quals. So I
> updated the postgresql_fdw patch to work with the latest FDW patch.
> Here. It's a bit of a mess, but it works for simple queries..
I'm going to set this CF item back to Waiting on Author, because (a)
there doesn't seem to be an actual concrete patch presented at the
moment, only a stack of hard-to-follow deltas, and (b) the patch
certainly needs updates for the extension mechanism and committed
FDW API anyway.
> It requires a small change to the FDW api
> (fdw-api-add-serverid-userid.patch). I added server oid and user oid
> fields to the FdwPlan - that seems like basic information that most
> FDW's will need, so it seems awkward to require the FDW to wrap them in
> Const nodes and a List.
FYI, I removed those fields from the committed API patch. I don't
think it's a good idea to cache potentially-changeable things in a
plan node when you can perfectly well fetch them at runtime. Caching
user OID is flat wrong anyway, as there's no guarantee that a cached
plan will be executed under the same userid it was made with.
regards, tom lane