Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1msWyU-0003zA-4V for pgsql-docs@arkaria.postgresql.org; Wed, 01 Dec 2021 21:17:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1msWyS-0005MN-3Q for pgsql-docs@arkaria.postgresql.org; Wed, 01 Dec 2021 21:17:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1msWyR-0005MC-Pd for pgsql-docs@lists.postgresql.org; Wed, 01 Dec 2021 21:17:07 +0000 Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1msWyP-0002dr-Bq for pgsql-docs@lists.postgresql.org; Wed, 01 Dec 2021 21:17:07 +0000 Received: by mail-wr1-x436.google.com with SMTP id s13so55243141wrb.3 for ; Wed, 01 Dec 2021 13:17:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=/vapg/JAxM/g3S72HW6DDT1CXTPBAXuLnbaOp8mY1HI=; b=EBKuQP5jLrVzNXSNpXBN48LafX8p6saRauWAsEIE39E77pktA66y0rVkKEotXlps2D 9hVz5/GPi1ufWVVDQb1hn5Cei2+ji2VBivr/DosYVtzKDOidE5VUxFkiCq4Xcub3LqsS Dio2SkFwZLKx9eTumaHOqcLyLv9ReL/vc/w/urPTE7HlXUKvQ+QHIRuFM1cKoSLy48wl j0t9ZAoD9Co1eFfpPYg2AWJZ6lF/y0HE2t+Q0Jna4DUjPuZyApuCLJfr01vYxRl6YjRc vVmN8Lf8Wy6iKYTFXBRsVWuPWyqL9qQNinkmp2txpO8DFi+xMsj/wsiVth/1qhqj4C2j 8fQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=/vapg/JAxM/g3S72HW6DDT1CXTPBAXuLnbaOp8mY1HI=; b=SwUBt35YAZCQgDpnQUrVVdNddT2S2w1cnN+Av4C+ErW5mvNVVT0A8LU0jq/SF6Lxc1 8B1Zzu1W48G6I0NI8zw0ieRaGLA3EEkMh03hx/K8929XCjdRzu9DvGrsyghqSz6Esf0E AvIFyUFyEAnNWmanCwytSZK+R2PXZCCpJbD3c9qyLmEd3+wtNFsTUXj/1fl7QJgz0ZvW nBQ4B27Rj2Uwe13ioN3QauOloK+yM6mo2idp3/CltRgOkCKY2HUuHo8NfI1uJjy13xEn FeHiM4goh1RxEYPnwuBql6/istcraBQkJb9GB2ZM46III2GoJW0MuHzOWqIKe/fifpKl dMtA== X-Gm-Message-State: AOAM533j3wA3FY64gdU7/moL8TLenWGHeQmst61S+ZT4SoK86Pq0UeGm OzZb8cLFQRncjFtM6vzMAUwkSQ== X-Google-Smtp-Source: ABdhPJyw9XsfFZJGhlX+nlK3cRTxKURABtWjMfVXSMhHjOsOHUT2VaM3prVgu7iZW/lxgr5UH2/b/A== X-Received: by 2002:adf:d22e:: with SMTP id k14mr9668126wrh.446.1638393423218; Wed, 01 Dec 2021 13:17:03 -0800 (PST) Received: from localhost.localdomain (178-190-179-120.adsl.highway.telekom.at. [178.190.179.120]) by smtp.gmail.com with ESMTPSA id b188sm341698wmd.45.2021.12.01.13.17.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Dec 2021 13:17:02 -0800 (PST) Message-ID: Subject: Re: Triggers on underlying tables of updatable views From: Laurenz Albe To: Max Ziermann , pgsql-docs@lists.postgresql.org Date: Wed, 01 Dec 2021 22:17:00 +0100 In-Reply-To: References: <163758281947.26190.10251137266467665332@wrigleys.postgresql.org> <2f54dbb7d59aacacbc4654b0bc56faaebe993e09.camel@cybertec.at> <3e14b477-40ce-4b6a-047a-9fea3843427c@htw-dresden.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, 2021-12-01 at 21:34 +0100, Max Ziermann wrote: > I'm not sure where in the docs a clarification could best be placed. For > me, the confusion arises from the fact that the updatable views section > on the CREATE VIEW docs aren't very clear what *actually* happens when > performing insert/update etc. through a view. It seems like the > distinction between "security context" and the actual user might be > helpful to understand the behaviour. > > With this background in mind, I still think that the wording "the user > performing the update does not need ANY permissions on the underlying > base relations" (from CREATE VIEW; emphasis mine) is misleading. > However, to me, it would be perfectly fine if this statement was scoped > to the actual insert/update on the base relation, thus excluding > triggered functions (unless SECURITY DEFINERs). You could send a documentation patch with your suggested wording. I agree that some more detail could be helpful. Yours, Laurenz Albe