On Thu, Oct 5, 2017 at 10:16 AM, Nico Williams
wrote:
> On Thu, Sep 14, 2017 at 04:08:08PM -0400, Robert Haas wrote:
> > On Thu, Sep 14, 2017 at 2:33 PM, Jeff Janes
> wrote:
> > > I think that foreign tables ought to behave as views do, where they
> run as
> > > the owner rather than the invoker
On Tue, Dec 5, 2017 at 8:35 AM, Robert Haas wrote:
> On Mon, Dec 4, 2017 at 5:57 PM, Ashutosh Bapat
> wrote:
> > I think the real behaviour can be described as something like this:
> >
> > "Only superusers may connect to foreign servers without password
> > authentication, so always specify the
On Thu, Oct 5, 2017 at 10:49 AM, Simon Riggs wrote:
> On 4 October 2017 at 18:13, Jeff Janes wrote:
>
>
> OK. And if you want the first one, you can wrap it in a view currently,
> but
> > if it were changed I don't know what you would do if you want the 2nd one
> > (other than having every u
On Wed, Dec 6, 2017 at 1:35 AM, Robert Haas wrote:
>>
>> "Only superusers may connect to foreign servers without password
>> authentication, so always specify the password
>> option for user mappings that may be used by non-superusers." But
>> which user mappings may be used by non-superusers can
Robert, Ashutosh,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Dec 4, 2017 at 5:57 PM, Ashutosh Bapat
> wrote:
> > I think the real behaviour can be described as something like this:
> >
> > "Only superusers may connect to foreign servers without password
> > authentication, so always s
On Mon, Dec 4, 2017 at 5:57 PM, Ashutosh Bapat
wrote:
> I think the real behaviour can be described as something like this:
>
> "Only superusers may connect to foreign servers without password
> authentication, so always specify the password
> option for user mappings that may be used by non-super
On Tue, Dec 5, 2017 at 2:49 AM, Robert Haas wrote:
> On Sun, Dec 3, 2017 at 3:42 PM, Stephen Frost wrote:
>> I'm not a fan of having *only* warning in the back-branches. What I
>> would think we'd do here is correct the back-branch documentation to be
>> correct, and then add a warning that it c
On Sun, Dec 3, 2017 at 3:42 PM, Stephen Frost wrote:
> I'm not a fan of having *only* warning in the back-branches. What I
> would think we'd do here is correct the back-branch documentation to be
> correct, and then add a warning that it changes in v11.
>
> You didn't suggest an actual change wr
Robert, all,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Dec 1, 2017 at 12:31 AM, Michael Paquier
> wrote:
> > I am moving this patch to next CF 2018-01.
>
> There now seems to be a consensus for superuser -> superuser_arg
> rather than what Jeff did originally; that approach has 4 vo
On Fri, Dec 1, 2017 at 12:31 AM, Michael Paquier
wrote:
> I am moving this patch to next CF 2018-01.
There now seems to be a consensus for superuser -> superuser_arg
rather than what Jeff did originally; that approach has 4 votes and
nothing else has more than 1. So, here's a patch that does it t
On Thu, Nov 30, 2017 at 12:15 PM, Ashutosh Bapat
wrote:
> On Wed, Nov 29, 2017 at 7:42 PM, Stephen Frost wrote:
>> Ashutosh,
>>
>> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>>> On Wed, Nov 29, 2017 at 4:56 AM, Stephen Frost wrote:
>>> > The "global rethink" being contemplated see
On Wed, Nov 29, 2017 at 7:42 PM, Stephen Frost wrote:
> Ashutosh,
>
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>> On Wed, Nov 29, 2017 at 4:56 AM, Stephen Frost wrote:
>> > The "global rethink" being contemplated seems to be more about
>> > authentication forwarding than it is ab
Ashutosh,
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> On Wed, Nov 29, 2017 at 4:56 AM, Stephen Frost wrote:
> > The "global rethink" being contemplated seems to be more about
> > authentication forwarding than it is about this specific change. If
> > there's some 'global rethink'
On Wed, Nov 29, 2017 at 4:56 AM, Stephen Frost wrote:
>
> Just to make it clear, I continue to agree with (3) and agree with Tom
> that we shouldn't be behaving differently depending on who is calling
> the view.
I also would vote for 3. That looks consistent with the way we handle
accesses base
Tom, Robert, all,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > OK, let me try to summarize where we are with this.
>
> > Currently, postgres_fdw requires a password unless you are logged in
> > as a superuser. Jeff proposes to change that so that it requires a
> > password i
Robert Haas writes:
> OK, let me try to summarize where we are with this.
> Currently, postgres_fdw requires a password unless you are logged in
> as a superuser. Jeff proposes to change that so that it requires a
> password if you are EITHER logged in as a superuser OR using a
> superuser's cre
On Thu, Oct 12, 2017 at 9:21 PM, Stephen Frost wrote:
> Yes, that means that sometimes when superusers run things they get
> permission denied errors. That's always been the case, and is correct.
OK, let me try to summarize where we are with this.
Currently, postgres_fdw requires a password unl
On Thu, Oct 5, 2017 at 1:16 PM, Nico Williams wrote:
>> That's an interesting point. I think that you can imagine use cases
>> for either method. Obviously, if what you want to do is drill a hole
>> through the Internet to another server and then expose it to some of
>> your fellow users, having
18 matches
Mail list logo
