| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 10:51:35 |
| Message-ID: | 4E2AA7B7.3090402@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 07/22/2011 11:34 AM, Robert Haas wrote:
>>
>>
>>> No, you can specify connection details at per-server and
>>> per-foreign-table level too. The FDW implementation is free to accept or
>>> reject options where-ever it wants.
>> Well, if we are going to take that viewpoint, then not having a user
>> mapping *shouldn't* be an error, for any use-case. What would be an
>> error would be not having the foreign-user-name-or-equivalent specified
>> anywhere in the applicable options, but it's up to the FDW to notice and
>> complain about that.
> +1.
What does the standard say?
You can get around most of the inconvenience with an empty PUBLIC user
mapping, although it's mildly annoying if you've forgotten to make one.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-07-23 11:40:12 | Re: cataloguing NOT NULL constraints |
| Previous Message | Andrew Dunstan | 2011-07-23 10:39:10 | Re: Policy on pulling in code from other projects? |