Hi Albe,
(2011/07/21 0:00), Albe Laurenz wrote:
> 1) GetUserMapping throws an error if there is no
> user mapping for the user (or PUBLIC).
> I think that it would be much more useful if
> it would return NULL or something similar instead.
> Otherwise one would have to check for existence
> beforehand, which is no less complicated than what
> GetUserMapping does.
Adding new parameter missing_ok and returning NULL for not-found might
be reasonable. BTW, what case do you want to handle the
nonexistence of user mapping by yourself?
> 2) If I decide to close remote database connections after
> use, I would like to do so where reasonable.
> I would like to keep the connection open between query
> planning and query execution and close it when the
> scan is done.
> The exception could be named prepared statements.
> Is there a way to tell if that is the case during
> planing or execution?
Only PlanForeignScan is called during planning (PREPARE), and others are
called in execution (EXECUTE), but this must miss your point.
It seems difficult to determine the planning is for simple SELECT or
PREPARE/EXECUTE, so you would need to keep the connection alive until
the end of local session to share the connection between planning and
execution.
> 3) I am confused by the order of function calls
> during execution of a subplan. It is like this:
> BeginForeignScan
> ReScanForeignScan
> IterateForeignScan
> IterateForeignScan
> ...
> ReScanForeignScan
> IterateForeignScan
> IterateForeignScan
> ...
> EndForeignScan
> So the first ReScan is done immediately after
> BeginForeignScan. Moreover, internal parameters are not
> set in the BeginForeignScan call.
>
> This is probably working as designed, but BeginForeignScan
> has no way to know whether it should execute a remote
> query or not. I ended up doing that in the first call to
> IterateForeignScan because I saw no other way.
>
> That seems a bit unfortunate. Is there an easy way to
> change that? If not, it should be documented.
Executing remote query only in BeginScan with current FDW API would be
difficult, and this issue can't be fixed in 9.1 release. So it would be
worth documenting that subplan's RescanForeignScan will be also called
before first IterateForeignScan call.
I'm planning to propose enhancement of FDW API in next CF for 9.2
release, so your comments are very valuable.
Regards,
--
Shigeru Hanada
