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 1rtV6A-00FDBO-1S for pgsql-general@arkaria.postgresql.org; Sun, 07 Apr 2024 16:10:26 +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 1rtV67-008iw4-OI for pgsql-general@arkaria.postgresql.org; Sun, 07 Apr 2024 16:10:23 +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 1rtV67-008ivw-DK for pgsql-general@lists.postgresql.org; Sun, 07 Apr 2024 16:10:23 +0000 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rtV63-001Pdh-GU for pgsql-general@lists.postgresql.org; Sun, 07 Apr 2024 16:10:22 +0000 Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-56829f41f81so5234711a12.2 for ; Sun, 07 Apr 2024 09:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712506217; x=1713111017; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=io7QjhL7dNa9DvJjA2YeB54Vrlu9Aw/SFdVkHMY+q6U=; b=K6ZOU4jPv06MG0Uzzdc4e1urlUamF00uaHlnqMj0rGqJRU5KgIpu60bhopYpgKtkk1 DFP6DKhVn/cEd0C/tcFsvTN8TUajozTRiEwyIvudMMmAcB98Nz4lg+WXIP3DP8jARgVR SiWGOd+tlHgD44H1jk+YYR7P+hJUDemrRSIVol1IJ7O3i6fOCdqlwof8Vvfw1ri6yVsY z7HqKmn5Oo36Cb6BWq8+m6C1CiOp9BjM1BRDSXJj4aGAwOcqw/+DjNS848p5zaeAyX8X xsiSbDJXONc5o2k+u+625IVFp2cl9oWo3gch8KfYjYMIGlelIIB8piuqVRLBlh9gs6vD P7dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712506217; x=1713111017; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=io7QjhL7dNa9DvJjA2YeB54Vrlu9Aw/SFdVkHMY+q6U=; b=whz9TJhfgaxR+iDSOGqF1Q0p7hoReHSXPXlB4U4GB5uf7Lm85vmA+XoUkOk+U09nQ1 AV0HyElr644jDr/zbWwDRn6KkuYDVCyNKsxyvu0NOwU7SBQPPcJcA0yUM98wR3tB10kz H/n7cr0llPiKHISChdMOiV4TOo8RNWSRnFG26pbzp9PZZtJo7dLQd4T4M6zdMPnXbbfb uKtOp3aFk8p66xopCS0e/e+6G8eUr9Sg73XKvsaDPJh3QvJRK4i67ten9iniwLgj55BZ /aqBzHaWZMQOlMD/7keKzWrhzP9A196HwCByCM0cdGXyZkgIJoL85tDKJycVDLn9ATZ9 YynA== X-Gm-Message-State: AOJu0YypbjlecMlvYytXacxZOAyOt4FqFn1q5IqL1JmRXTsH4NY5E4LB b2dghu2rJdbksX54o4mUghLN3mf0bbTl7GTzyHVLJ1063P2wHWNDaILTJXPDNfuZtBFLXmwdMti sjBcyN3jBGQ8a0KK/5+Nlw2j93BqI7PKJ64w= X-Google-Smtp-Source: AGHT+IFrc456W97PYWnVmAdbRptCzwjWGsYeVcRcgBpBSa4DY7E4fRPEnc8vOYm/D7+zsqlVhl3C0S/E23lxP9x87oU= X-Received: by 2002:a50:9e84:0:b0:56c:24e6:ca7e with SMTP id a4-20020a509e84000000b0056c24e6ca7emr4148989edf.2.1712506216886; Sun, 07 Apr 2024 09:10:16 -0700 (PDT) MIME-Version: 1.0 From: Ayush Vatsa Date: Sun, 7 Apr 2024 21:40:05 +0530 Message-ID: Subject: Clarification on View Privileges and Operator Execution in PostgreSQL To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000bbbc2d061583ecd6" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000bbbc2d061583ecd6 Content-Type: text/plain; charset="UTF-8" Hi PostgreSQL community, I am recently studying about operators and views and I had doubts in two small things 1. I know if a view (security definer) is accessing a table then it is getting accessed by view owners privileges but what about the view which contains inbuilt operators or inbuilt functions with whose privileges those will be executed. Eg. SET ROLE postgres; CREATE TABLE x(id INT); CREATE VIEW v AS SELECT * FROM x WHERE id > 100; CREATE ROLE alex; GRANT SELECT ON v TO alex; SET ROLE alex; SELECT * FROM v; Now table x will be accessed (SELECT * FROM x) with "postgres" privileges but who will execute the underlying function inside the ( > ) operator ? Is it postgres or alex? 2. What if I used a user defined operator in the above example, then with whose privileges that operator will be executed? Thanks Ayush Vatsa SDE AWS --000000000000bbbc2d061583ecd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi PostgreSQL community,
I am recently studying about = operators and views and I had doubts in two small things
1. I kno= w if a view (security definer) is accessing a table=C2=A0then it is getting= accessed by view owners privileges=C2=A0
but what about the view= which contains inbuilt operators or inbuilt functions with whose privilege= s those will be executed. Eg.
SET ROLE postgres;
CREATE= TABLE x(id INT);
CREATE VIEW v AS SELECT * FROM x WHERE id > = 100;
CREATE ROLE alex;
GRANT SELECT ON v TO alex;
=
SET ROLE alex;
SELECT * FROM v;

Now= table x will be accessed (SELECT * FROM x) with "postgres"=C2=A0= privileges but who will execute the=C2=A0
underlying function ins= ide the ( > ) operator ? Is it postgres or alex?

2. What if I used a user defined operator in the above example, then with= whose privileges that operator will be executed?

= Thanks
Ayush Vatsa
SDE AWS
--000000000000bbbc2d061583ecd6--