Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tr1m5-00DgOi-6Y for pgsql-hackers@arkaria.postgresql.org; Sat, 08 Mar 2025 21:32:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tr1m3-009SLb-Oh for pgsql-hackers@arkaria.postgresql.org; Sat, 08 Mar 2025 21:31:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tr1m3-009SLL-CP for pgsql-hackers@lists.postgresql.org; Sat, 08 Mar 2025 21:31:59 +0000 Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tr1lx-001kFY-0t for pgsql-hackers@postgresql.org; Sat, 08 Mar 2025 21:31:56 +0000 Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5e5e1a38c1aso2288636a12.2 for ; Sat, 08 Mar 2025 13:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741469514; x=1742074314; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=t1yktMfv/elQx50stlTaKCQohGL31m2NrW/tSyXJt7g=; b=g36yGC47CfhAwMRry+Mq/3AcZpX8A9lJnwxGP5B8c0feWxrs8jv5APZL8BIkJRPvpM 03vNsZFDeEjePzEe3XAgagsLaf0utH3dIztOCVSOm+dpOUFxlvYzgQagglw7Mv3KQDiO ke7XfqLHStPgfT/AkyEggLmeVjuFE/fOjJNot+qJAD5CJ41C5SrX+HXdGEzahl7DDFaB BcjoYdIjmRFDwnoKbgHD8kjuv4j9fJ2a+BsiGq+8lJhsiGvcxFEOZoT61EDQ1K/pU6Oo oktLfdF+/RFVJ2EHcaEgOL0/u7CAVMlrbq5TGApBrhVz8JetxuP4xXfJUP2NZ1kDOsw6 KtMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741469514; x=1742074314; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=t1yktMfv/elQx50stlTaKCQohGL31m2NrW/tSyXJt7g=; b=TMGfmhQT1IbgXrHrMk/4LT5yuyiUFfcx5O7sqTwn1m0Lg0fWfNBVkUl8VsUnmemykx bI8U8l0DGtkog4Dkd5xd4PSuiHPXIIbuvwFZCL6Du6x9rl0y7CFm/uC+mKDt5LtNvX8M mef4LJvrYaZsd3mUjo9t66mybxZIL1/cI5PDkI9/1dowth4cDlrF7z2Ri3+KcGQMy9fu oUzXB/a0Y/CmceF9y9+DBC3RjtdxoKZ+RVnTVviLGy3yIJYwXv0hQU2br7FqPOA5AmKE RuRdx83+JDNsY1Vg5nnRbyEsrPtI1cWg/juagXUPdpNNX/RsmXnKEyJHe0XfSu+H2Zy4 etgg== X-Forwarded-Encrypted: i=1; AJvYcCV7G103B44fdpFU6zeb5AWIxJBmnG7x2FXSnx8X8lfouvabMsMIiNQqmtZt/6AbZjrzYJKriI6dIEaBMkFq@postgresql.org X-Gm-Message-State: AOJu0Yy98gFPkqsEbbtYMIPTY2uNYxgm91YlwSSPl+aE605uv/XsKRVF 25Fmh2CqXjp46j7OhBWwJFzpesn3VOFlOzySadt+cw0vVwNYcG2xcl27aEAbS896+xYzmPh45W6 56hB115HZtCNshbwozZnqXT/WOz0= X-Gm-Gg: ASbGncvWmu1xeAgq63TINCp1uBXywfAO3IbA6GZvpwejTvRQpxXs9HQPV5DhlVQz3F7 MV7rpGSUPQyaj/RkPOyxZ8uNQDZzNXpCZDrII/A+FYPCMWobbdjEZW+Hjul/uBWrxDlBJ3mt3Fu J/5P+w54UjIw4KhOmZ60a7Eh4= X-Google-Smtp-Source: AGHT+IFgD61zkTJlorpvJ7DW2CDhVy5ZGhNtiNDflajHXiA6FVOaRrkgIwR30vtml6pDoMoZfPTDabdEt1tRfLmpNHo= X-Received: by 2002:a05:6402:1d54:b0:5e4:9348:72e3 with SMTP id 4fb4d7f45d1cf-5e5e24689cemr16834902a12.21.1741469513195; Sat, 08 Mar 2025 13:31:53 -0800 (PST) MIME-Version: 1.0 References: <934709.1739829723@sss.pgh.pa.us> <1243984.1739894558@sss.pgh.pa.us> <1246906.1739896202@sss.pgh.pa.us> In-Reply-To: From: Ayush Vatsa Date: Sun, 9 Mar 2025 03:01:41 +0530 X-Gm-Features: AQ5f1JqD68QGGnpqY6p2gS3pe00IdyyrAwHLcrwZWPd8CTLDWxeFQdVe1d377pI Message-ID: Subject: Re: Clarification on Role Access Rights to Table Indexes To: Nathan Bossart Cc: Robert Haas , Tom Lane , "David G. Johnston" , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="000000000000b8a92b062fdb77b0" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000b8a92b062fdb77b0 Content-Type: text/plain; charset="UTF-8" > From a quick test and skim of the relevant > code, I think your patch is fine, though Thanks for reviewing. > And IIUC > DROP TABLE first acquires a lock on the table and its dependent objects > (e.g., indexes) before any actual deletions, so AFAICT there's no problem > with using it in pg_class_aclcheck() and get_rel_name(), either. True, I have also verified that from [1], hence I think we are safe here. Maybe we can move ahead with the patch if we can see no other concerns. [1] https://github.com/postgres/postgres/blob/master/src/backend/catalog/dependency.c#L398-L430 Thanks, Ayush Vatsa SDE AWS --000000000000b8a92b062fdb77b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> From a quick test and skim of the relevant
> co= de, I think your patch is fine, though
Thanks for reviewing.

> And IIUC
> DROP TABLE first acquires a lock on the tab= le and its dependent objects
> (e.g., indexes) before any actual dele= tions, so AFAICT there's no problem
> with using it in pg_class_a= clcheck() and get_rel_name(), either.
True, I have also verified that f= rom [1], hence I think we are safe here.
Maybe we can move ahead with th= e patch if we can see no other concerns.


= Thanks,
Ayush Vatsa
SDE AWS
--000000000000b8a92b062fdb77b0--