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.96) (envelope-from ) id 1w73Pc-004ulf-2M for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Mar 2026 03:35:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w73Pb-000yBE-0m for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Mar 2026 03:35:35 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w73Pa-000yB3-32 for pgsql-hackers@lists.postgresql.org; Mon, 30 Mar 2026 03:35:35 +0000 Received: from mail-oa1-x2c.google.com ([2001:4860:4864:20::2c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w73PY-00000001k3U-3eMO for pgsql-hackers@postgresql.org; Mon, 30 Mar 2026 03:35:33 +0000 Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-40429b1d8baso1504304fac.0 for ; Sun, 29 Mar 2026 20:35:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774841732; cv=none; d=google.com; s=arc-20240605; b=Tzib4knBVgb/222cePmDbCZjkKPXAz4KVtf4rztdxLVdBgzX8OZsLShfMpHI48f5OS FM2klap9ED1jGsKRoHSscLc24FMyzAtu58hSrQPmc1ck2oKwd4FQiQ2zaSUSH9hOIi7h C1sggve/fExVRC2dKb+AOqiDS/J0RIsNCBCeML6v/T9oF13Ss2kfSwY1YnbI4G+KjhLs mb7oDnOAk+FodhSouoiIAKOLy9SbzwL/1iriu2lxwaNcs+8kqay6E0ZVv/soDwQIrx7i qybCMX87/BSXA8gy6RvCmm7S4CBi2gS3nxg0y/hIX5nNkCpFbaK4jnvHQUUf1Vq06cc9 xpag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=giOnJuRNOkKhZOl8I6R5r0EpFsCFGXGX/g6NHfmsccI=; fh=zoRFi4vqyblac5YGSUJxae8nhQ5jpL9RmI3ky3M0sTQ=; b=GrvcecLoEEIhXAx9te9lo+s8YQFjz7JIdz1KSJ02PWEWBizHBerpHz/YluzKut+P/0 n4abn23Klo63JJf17Yvz92oE4pPV/Cs1bgU4lTTqth7Pu2DZQPFlY6/b/gk1W6ylnuzN SCNY3C74bdRlmivsJlYzZitfkxgyKvLoPeF66WXjNr2IPPaRhKaTSoI5sAdxeG/4ijx+ lVczb0Guv+c7i9n4WDZ1eoqleUb2oLH0GSETd751qUZGl5S1R2IM6P4PdE/02/D2U/Js obdfybsuGl1mVhfOo5qG/phbwUomoZL0otjRvMeiYPwqtQaUd4hSq9y+JkVocaRONZj3 HoLQ==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774841732; x=1775446532; 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=giOnJuRNOkKhZOl8I6R5r0EpFsCFGXGX/g6NHfmsccI=; b=JLoCqGeMDh/StOma92Xpjd7NetQrP2WCxBlBsRBHhLOXjdyiQ/kDadHRZgPU6Bqoql NMOJKRcIhlZsKbCkKdrc5IDRpENkUsX5r8VfOt3Hwnw4C98Ru44TjdQCMX2OeWh+7ykI f7kJBotEH/CfH56THhcFex9I6vyInJAcosQ8IeZbrTMGamndTBYuAUmGioiinpFWzsB/ gA33yFqh5JGf2mucONj8RbR54dqJ6neh1HWuwkwt2ZnlpdJ11Pwx3kIITouEQl3pIOpg lxKSNpqll03eFQPfWp4h4eYL2Apx+ZnND+0MCIuyuxwwDBXQ8BcnsbhVZiPpNZFW2Gcx +sww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774841732; x=1775446532; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=giOnJuRNOkKhZOl8I6R5r0EpFsCFGXGX/g6NHfmsccI=; b=NLn+Vgc6AOzYGtA53iQlCMIHzle/cKgveL+fTIdf07VUrHyhBwDkeFc0biG7I7g9yg C/WC9U0FpXo55nE/7VqI9dVdboBhgKCVw6uoFoi/Br2VSuymddFiIsAtO+vfqutn+Wnw ksxyBS7CGq++7OeFdaMhdq1u9zjJk7a0v4fYjUauzKxB7onfBVtBxeqClqQk9H2jXnWO MXWl1+CXR5XYFEi2KYkLozp4rhTXSPv9GXHxMiVMBHQSG3oJGjHp10EXBbQPqjbS1iV6 SK7xQayUltrDdCLckholdMmDtEgEIIPlv8brsgIoOO8XsaK0Eg08E3gkkNLL5moVnRyw WlcA== X-Gm-Message-State: AOJu0YyiE/e1VYQFWlMX83wYvHxmynjDpZPIERDuDtsJtvh4Zz8VbS4R PNA/2AdV7br5rF5kJjMOPzZaoPyaSBR7FSW4mA3IdBUcHm1nlR7sNbGpIaFmq+WpRNliXR6FiT2 5cIT2tsZSCMc2Pu9s/gR3Bgr3LXUZ510= X-Gm-Gg: ATEYQzyBENSi7B+45fV13fIPX6ew0+4lgcLAjjjrPJfRvF7P9ooIdSKspL+ivCiUbBV Ds4KEwjBOl019SY/GicMkH2TvYGDBCp7sr3a9Dw496IhloK0P61H9dElkvzttKq0Wc8QSTE2vh4 X9T8InJfca5vutEjGh/jVKFkUMUEEdKw0f58xioM1A1MbcmOhsAdV2g9WEYwrmCzdcnxYOP5aVI OvtfVpU/Pdxh+W99wS7J+D4QHa7Ne3bxDeoliasIAxyxw7bg99Ev6lHrS5jDbCIWlZczAgWeRwm 5KkjLNqTFBXLOHc3qMknUdQPnGrUG/qbXZXOwQw= X-Received: by 2002:a05:6870:63aa:b0:417:3767:bf11 with SMTP id 586e51a60fabf-41cec38428emr5429958fac.47.1774841732300; Sun, 29 Mar 2026 20:35:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "David G. Johnston" Date: Sun, 29 Mar 2026 20:34:56 -0700 X-Gm-Features: AQROBzAfWopn8t-r38Pt1zdGzU9Nbcq4lo_EjWHBsC9hJxcbgaAhmdoKGy-6DiI Message-ID: Subject: Re: [PATCH] Report column-level error when lacking privilege To: Steve Chavez Cc: PostgreSQL-development Content-Type: multipart/alternative; boundary="000000000000fc85ca064e358a20" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000fc85ca064e358a20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 29, 2026 at 6:07=E2=80=AFPM Steve Chavez wr= ote: > When a role `xx` has `grant select (name) on items to xx;`, a generic > table-level error is given: > > select * from items; > ERROR: permission denied for table items > > With this patch, we now give: > > select * from items; > ERROR: permission denied for column "id" of relation "items" > > Not too fond of picking one column as a representative for the error message. Better to say something like: ERROR: permission denied for column subset of table items Haven't looked but it should be doable to run a query for a given relation and role and report for each column whether a grant is available or not; which would be the one-stop shop for figuring out which columns at least don't have permissions granted. The user would still have to know which ones their query is actually using. David J. --000000000000fc85ca064e358a20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Mar 29, 2026 at 6:07=E2=80=AFPM S= teve Chavez <stev= e@supabase.io> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
When= a role `xx` has `grant select (name) on items to xx;`, a generic table-lev= el error is given:

select * from items;
ERROR: =C2=A0permi= ssion denied for table items

With this patch, we now give:

se= lect * from items;
ERROR: =C2=A0permission denied for column "id&qu= ot; of relation "items"


=
Not too fond of picking one column as a representative for the err= or message.=C2=A0 Better to say something like:

ERROR:= =C2=A0 permission denied for column subset of table items

Haven't looked but it should be doable to run a query for a given= relation and role and report for each column whether a grant is available = or not; which would be the one-stop shop for figuring out which columns at = least don't have permissions granted.=C2=A0 The user would still have t= o know which ones their query is actually using.

David= J.

--000000000000fc85ca064e358a20--