Re: Questions and experiences writing a Foreign Data Wrapper
От | Robert Haas |
---|---|
Тема | Re: Questions and experiences writing a Foreign Data Wrapper |
Дата | |
Msg-id | CA+Tgmoa+caEaLRxvqgpORcE3_o7hewKNc5Pj5h1JUy6Mv=Ad_w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Questions and experiences writing a Foreign Data Wrapper (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Questions and experiences writing a Foreign Data Wrapper
|
Список | pgsql-hackers |
On Fri, Jul 22, 2011 at 12:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Fri, Jul 22, 2011 at 12:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> In particular I find the following in SQL-MED:2008 4.14.1: >>> >>> NOTE 9 - Privileges granted on foreign tables are not privileges to use >>> the data constituting foreign tables, but privileges to use the >>> definitions of the foreign tables. The privileges to access the data >>> constituting the foreign tables are enforced by the foreign server, >>> based on the user mapping. Consequently, a request by an SQL-client to >>> access external data may raise exceptions. > >> I read that to mean that the remote side might chuck an error >> depending on the credentials used to connect. I don't read it to be >> saying that the local side is required to do anything in particular. > > Well, if you read it that way, then CREATE USER MAPPING with an empty > option set is a no-op: the behavior of the FDW would be the same whether > you'd executed it or not. Which doesn't seem to me to satisfy the > principle of least surprise, nor the letter of the spec. I think what they're saying is that they expect the credentials to be stored in the user mapping. But that seems like a fairly silly requirement, since it's not difficult to imagine wanting all of your local users to connect to the remote side with the same set of credentials; or wanting, perhaps, to connect to some data source that doesn't even require credentials, like a CSV file. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: