Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iVhUN-0007vL-Jj for pgsql-docs@arkaria.postgresql.org; Fri, 15 Nov 2019 19:42:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iVhUM-0003jZ-8B for pgsql-docs@arkaria.postgresql.org; Fri, 15 Nov 2019 19:42:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iVhUL-0003jS-RV for pgsql-docs@lists.postgresql.org; Fri, 15 Nov 2019 19:42:38 +0000 Received: from mail-qv1-xf44.google.com ([2607:f8b0:4864:20::f44]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iVhUE-0008AI-Me for pgsql-docs@lists.postgresql.org; Fri, 15 Nov 2019 19:42:36 +0000 Received: by mail-qv1-xf44.google.com with SMTP id cg2so4208851qvb.10 for ; Fri, 15 Nov 2019 11:42:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NOtvvkucEJU7a5bH/zP6pX6lt4WS8Eb1wdqDZg/S4Mo=; b=exgRlpBXz7QTZDH0KmtDMVvHDtlBJdlg1tUBBuM6v9CbuLFubtLR+oyCodFs/xmO/U 71Sk3Uh6a7y4T47M2w4yKzV7RZlX4IYenI96V+Puxv4WRKe3bVF8XVcK8W3sCJTy3Tl5 x/QtYzc0/8cGf7pek+dMRsZwrcCzN9U2z1wZvsA8GpouXXPBpl/cTtVJ4IzoBLMIXXeI uri5wJv1B0gdsOmfPj4T6Ht6yiSJEm6H4+EF7LL32uqlzRhBzEAcNmI1iiOpVCaARcTr jgbofYd0Uqpp/NddMdo3KX6mv1cM8BuJ9fmcgOgqxfOn/IpEfuUb5e0guRjElBF4Mjzv HfdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NOtvvkucEJU7a5bH/zP6pX6lt4WS8Eb1wdqDZg/S4Mo=; b=AzO/NF9dCLaq0QQ5V4SHC9QbM0Z88wh/daaOpx715ruQ5oGF+3CdTat67uvGPa1zcN 8ORhhovTcVTi4F3pLr2uf2KkwP66/9a9Mphq4xNEpHzAFzFOu6g9Igp2mxeXZyzY344W pyhq6h9OaQ+4hZkCbU1YlmudRfSNCGc70QVCwsydR3n5hURe2H7/SgcVp4uAfABFt3GR DUyELDnxmEtECUwXvqC9mz/u9s6OKVi5jhvznxXnMTcveAjIVwSMfwmYQ9uSBxvYEDx1 I6e+UP5lk492WMDrDwS56LJfPzA+yjyqJw0hJiRaLVzuZ7SldojE+49Jl5xIaDY/WJ/i zk/A== X-Gm-Message-State: APjAAAXJJ9A3DBkFlSYk1Xe9ALgR5/u4al1YSDNLWL8CyDaqk46dRoeV 8IA5ylF2YGPc8iO597ttaOur67ftjGyRgy0eTwk= X-Google-Smtp-Source: APXvYqyW5M9JXLJLs0RQ87Amjp5pQCBCG4WqWJSw8GtN/R2Nelx5N4aq5FzCiDkuDlpQd8b+WIBquPCTqTC0kEMuyrA= X-Received: by 2002:a0c:fecf:: with SMTP id z15mr15297949qvs.27.1573846949345; Fri, 15 Nov 2019 11:42:29 -0800 (PST) MIME-Version: 1.0 References: <157377058468.1209.1912214624357780577@wrigleys.postgresql.org> <11507.1573844676@sss.pgh.pa.us> In-Reply-To: <11507.1573844676@sss.pgh.pa.us> From: "David G. Johnston" Date: Fri, 15 Nov 2019 12:42:16 -0700 Message-ID: Subject: Re: no mention of GRANT USAGE in postgres_fdw docs To: Tom Lane Cc: joe@nahmias.net, pgsql-docs@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000058c144059767cc5d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --00000000000058c144059767cc5d Content-Type: text/plain; charset="UTF-8" On Fri, Nov 15, 2019 at 12:05 PM Tom Lane wrote: > PG Doc comments form writes: > > The documentation page for postgres_fdw > > gives a nice > > step by step on what's needed to configure a FOREIGN SERVER. However, > one > > crucial step is missed, and that is that you need to issue GRANT USAGE ON > > FOREIGN SERVER before you can successfully run step 4, IMPORT FOREIGN > > SCHEMA. > > That paragraph links to the IMPORT FOREIGN SCHEMA reference page, > which says > > To use IMPORT FOREIGN SCHEMA, the user must have USAGE privilege on > the foreign server, as well as CREATE privilege on the target schema. > > I'm not clear why we should duplicate that information here, especially > when we're not duplicating any of the other essential information about > how to use IMPORT FOREIGN SCHEMA. Nor does this summary mention the > privilege requirements for any of the other commands it suggests using. > The overview page says: "Create a user mapping, using CREATE USER MAPPING, for each database user you want to allow to access each foreign server." It seems reasonable to add that you need to grant those same users the USAGE privilege on each foreign server as well. The bullet list does seem like it is inclusive of all the major SQL Commands that are needed to make this work and since it doesn't just speak of setting up the owner's permissions mentioning GRANT, while slightly redundant, seems in scope. David J. --00000000000058c144059767cc5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 15, 2019 at 12:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
<= /div>
PG Doc comments form <noreply@postgresql.org> writes:
> The documentation page for postgres_fdw
> <https://www.postgresql.org/docs/cu= rrent/postgres-fdw.html> gives a nice
> step by step on what's needed to configure a FOREIGN SERVER.=C2=A0= However, one
> crucial step is missed, and that is that you need to issue GRANT USAGE= ON
> FOREIGN SERVER before you can successfully run step 4, IMPORT FOREIGN<= br> > SCHEMA.

That paragraph links to the IMPORT FOREIGN SCHEMA reference page,
which says

=C2=A0 =C2=A0 To use IMPORT FOREIGN SCHEMA, the user must have USAGE privil= ege on
=C2=A0 =C2=A0 the foreign server, as well as CREATE privilege on the target= schema.

I'm not clear why we should duplicate that information here, especially=
when we're not duplicating any of the other essential information about=
how to use IMPORT FOREIGN SCHEMA.=C2=A0 Nor does this summary mention the privilege requirements for any of the other commands it suggests using.
=

The overview page says: "Create a user = mapping, using CREATE USER MAPPING, for each database user you want to allo= w to access each foreign server."=C2=A0 It seems reasonable to add tha= t you need to grant those same users the USAGE privilege on each foreign se= rver as well.=C2=A0 The bullet list does seem like it is inclusive of all t= he major SQL Commands that are needed to make this work and since it doesn&= #39;t just speak of setting up the owner's permissions mentioning GRANT= , while slightly redundant, seems in scope.

David J.

--00000000000058c144059767cc5d--