From: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "Tom Lane *EXTERN*" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Questions and experiences writing a Foreign Data Wrapper |
Date: | 2011-07-22 08:08:53 |
Message-ID: | D960CB61B694CF459DCFB4B0128514C206ABA29A@exadv11.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane 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.
> We could make it do that, but under what circumstances would it be
> useful to not throw an error? It doesn't seem like you should try
> to establish a remote connection anyway, if there's no mapping.
I guess I misunderstood the concept of user mapping.
I assumed that the user of the mapping is the table owner and
the mapping provides default values for all foreign tables
the user owns.
Does it refer to the user that executes a query?
Or is a user mapping intended to be the only source of
connection information?
I guess it is time to read my SQL Standard, but some clarification
in the documentation sure wouldn't hurt.
>> 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'd say it probably shouldn't, ever. If you look at the executor's
node
> init functions, none of them do any actual data fetching. They just
> prepare data structures.
That might also be a good thing to document.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Harshitha S | 2011-07-22 09:00:28 | Tracing in Postgres |
Previous Message | Heikki Linnakangas | 2011-07-22 07:34:32 | Re: Re: [COMMITTERS] pgsql: Remove O(N^2) performance issue with multiple SAVEPOINTs. |