From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Questions and experiences writing a Foreign Data Wrapper |
Date: | 2011-07-23 14:54:33 |
Message-ID: | 4E2AE0A9.7090205@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 07/23/2011 10:42 AM, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>> What does the standard say?
> Well, there is not a statement in so many words that you have to have a
> relevant USER MAPPING to use a foreign table. But the spec does specify
> that an FDW's ConnectServer function takes a UserHandle as one input
> parameter and should throw an exception if that handle isn't valid.
> And as far as I can tell a UserHandle can only be created from a
> relevant USER MAPPING entry. So I think the behavior I'm arguing for
> would emerge from an FDW that was built using the spec-defined API.
> We only have an opportunity to argue about it because we chose to
> invent our own FDW API.
>
>
In that case I think I'm in favor of the suggestion of an implied empty
user mapping for PUBLIC, as long as it can be overridden.
It does seem to be very late in the day to be arguing about such
details, though, unless we're talking about changing it in the 9.2 cycle.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-07-23 14:58:37 | Re: Questions and experiences writing a Foreign Data Wrapper |
Previous Message | Dimitri Fontaine | 2011-07-23 14:45:16 | Re: proposal: a validator for configuration files |