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.92) (envelope-from ) id 1j6Wvb-0008Vc-Vc for pgsql-docs@arkaria.postgresql.org; Tue, 25 Feb 2020 09:55:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j6Wva-0005Lg-OU for pgsql-docs@arkaria.postgresql.org; Tue, 25 Feb 2020 09:54:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j6Wva-0005LZ-GU for pgsql-docs@lists.postgresql.org; Tue, 25 Feb 2020 09:54:58 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j6WvW-00034Y-AY for pgsql-docs@lists.postgresql.org; Tue, 25 Feb 2020 09:54:58 +0000 Received: by mail-wm1-x344.google.com with SMTP id a9so2441031wmj.3 for ; Tue, 25 Feb 2020 01:54:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=tOzGvDAqqjYfKmXOCtm/CTtA8U/AOIDxS7X8dLyKSe0=; b=juG2EhV2YCMP1V/hrdHjMaPbVHKbiuUKHvgSuspH7WsgWt+E/T7RHA41pqbRLFYWBl yuk9IxDhksOpbUPH8AbHOGUjAP7bar3F1Ajeq3l/lCSiTp5TpepVQOAwFl8zvKg2Lfms BKBeN5cmMI3o4BGbsRMh5u/XvXMxfEmfiCCZ45Zh3M761LWZ10c0OUqbhFCF6KsbQ5sA 74EDwxeESZJg1XijdqRiRuM7rNI4LPDJ3MkLn6ZG3FTbFISEnipbNn1GXcQFG8dpAdqT vM0ux+Nb8b2pKnRBR7IKOmQlDASbLTgrdHBy2b/ig7/CLrOLvJ2sEmlVLzt+pD4Rt5gA jNuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=tOzGvDAqqjYfKmXOCtm/CTtA8U/AOIDxS7X8dLyKSe0=; b=iuinqsXckeQXQWXcM40K6JSutyZr62kyTbRiCBRVsFo5H03s02fxW5P0H0+GF3ivyB SxG7lhVempeHnz6fPdKK0UTu4efLKME9oXCnZWk3r9RNiJOzMektyElLUxclHa3soKM0 IujTTudc1QZpGWGDZiMZFBwJRh0jeG0+rUUDP3Gvl1eoLDSKzz/kpqYI+tR2aHsRx+8v b35YHXOrTjTIvIWKkTTREAmKRKe9Vn4Ue9PQq4K0iseOJpU6AXbEqUk9SxbXS8zRn1BC VkhrFERH9EQfGD7pb8DpEXDJX5kHrAaB5ytiVuu1HOYwuUKQx0JTeNuMOS7czusSr7HC pP7A== X-Gm-Message-State: APjAAAVN8Vg3SdVEHUYwE4Yt76WbNhY9nmWd3Cq/syBFJ+4m37iHQBcF VUjaDaH8m9/bpfA4c/GOi1SisQ== X-Google-Smtp-Source: APXvYqweNbqnWHBOpkeSAznYmBk5M1jk9+RozfPMCNj36iZZ/UjZQY5tdrMT3DHoU4MTVFRXUR1OAg== X-Received: by 2002:a1c:6884:: with SMTP id d126mr3136444wmc.38.1582624493115; Tue, 25 Feb 2020 01:54:53 -0800 (PST) Received: from localhost.localdomain (217-149-174-158.nat.highway.telekom.at. [217.149.174.158]) by smtp.gmail.com with ESMTPSA id z19sm3401296wmi.35.2020.02.25.01.54.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Feb 2020 01:54:52 -0800 (PST) Message-ID: Subject: Re: No docs for interaction of ON DELETE/UPDATE and permissions From: Laurenz Albe To: David Glasser , pgsql-docs@lists.postgresql.org Date: Tue, 25 Feb 2020 10:54:52 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, 2020-02-24 at 14:45 -0800, David Glasser wrote: > I was planning to add a new table TA only writable by user A, with a foreign key reference with > ON DELETE CASCADE to another table TB only writable by user B. My hope was that user B would > still be allowed to delete rows in TB and cause cascading deletions in table TA, and some manual > investigation makes it seem like that is the implemented semantics. > > However, I could not find a direct answer to my question in the docs. I looked primarily at > https://www.postgresql.org/docs/current/sql-grant.html and https://www.postgresql.org/docs/current/sql-createtable.html . > There are references to permissions required to create references, but not to the permissions > (not, apparently) required to indirectly write to a table via referential actions. > > Am I correct that (a) no permissions are needed here and (b) this is undocumented and (c) it would > be helpful to document this, probably in the CREATE TABLE docs? Happy to write a patch if so. I would say that it is not documented outside the source, and I think it wouldn't harm to document that. I had to dig in the source myself the first time I encountered that. I am not sure if CREATE TABLE is the perfect place; another place that would offer ifself is https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-FK , where foreign key constraints are explained. Yours, Laurenz Albe