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 1tTjiY-009LfN-P7 for pgsql-general@arkaria.postgresql.org; Fri, 03 Jan 2025 15:36:07 +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 1tTjhZ-002kLq-6N for pgsql-general@arkaria.postgresql.org; Fri, 03 Jan 2025 15:35:04 +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 1tTjhY-002kLh-PO for pgsql-general@lists.postgresql.org; Fri, 03 Jan 2025 15:35:04 +0000 Received: from mail-oi1-x22e.google.com ([2607:f8b0:4864:20::22e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tTjhV-00039B-1f for pgsql-general@lists.postgresql.org; Fri, 03 Jan 2025 15:35:02 +0000 Received: by mail-oi1-x22e.google.com with SMTP id 5614622812f47-3eb8accbde3so6485061b6e.0 for ; Fri, 03 Jan 2025 07:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735918498; x=1736523298; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9HufnJ+W7wSaWygpEr2qBlJveJrTChgjb1ireCQ+tO4=; b=kjPJnrDGDDOMKkjUyP4Hlb4pdIa284VV/xef/05MVuicqsRIVlUq2meIvXCG68dj7Q 1tIwgAogjZ3oYATw/HBsWlQ1dvN0xdJ5jlRKnQ6XMEvG08sRCjb5sWuAyJ24XY/QyjNJ Jw/Ukv63msBkmfTi+Lc/DbQrUTNv7rglhxVj2+rxL6mqw+uuS54Wjg7H8uUj6UpwfR+G /TPEctGBfax24NHIE+0gKBwo3dg60eATRPTAATv1So0/BSj30i96GhznTCMdTUhSTj8K x6GLhvIdqncxq09ao/gnuvIuQPwB8JT2WiZ8x3tUsDDqnuVL65EKFHK/ei5pzFedk9fE cbaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735918498; x=1736523298; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9HufnJ+W7wSaWygpEr2qBlJveJrTChgjb1ireCQ+tO4=; b=bzpwZ4yC10IgcqFF5ty8fD4QHMBEskHQT160PmuLYL6bHAcx6Y8GGAaEqbrYNuoEDx PpuEK5x2zbIGAXOSAoFk8JPEl/ovHy1qAHhpQh8A/8zyR2JCuy4aOndgHKtwYYEJarzm pjZ/TF8g8uS8WqwiO2m+g1roi71BdhK+QjGcBTtjsa8StkByh57qBRT/KfmBIYMJUyax 3eVQYVtfZxIqck+uLSDeminaLUdIiRYTMu1iG+1JeA68dkXrPivSPbxy7kaxvYnluGlB /4UmtVC1KlPcS7HF7rW15jToszyAg+EODaOdi9/L+FiRW+Ff+w713EUZB8gn+HmkpPC6 WAyQ== X-Gm-Message-State: AOJu0Yw4XPhY9sFpt30Vxwho7zuhtcjq4f2W/e1uemgbUMCkLpz00IhZ UGdQUfveGdbHqU0Dp6IaDKJurz4rasW8F1PhiOeSUpbcXFoUS9EKg1/VLr0Tp0Mx+hnNCQ6mY35 SGRU31Hu9SLsgedpHGmzeqL+paWBKcbM8 X-Gm-Gg: ASbGncue3/g+yYKtp+JQoRTnaXzmkhrAje4Qfrs1BRlceURq5kqZy5l5Wq1+1fyDi6d hCIvzt1kDNnRseryuWyjA3JFa6HGbUY3UQhAdfQ== X-Google-Smtp-Source: AGHT+IGhItY+mN4LL4kS3P7c9zh6T6aHnD2JEsTAiRTaigy8V7gk5FTGfKigukpDICZ3WQA9SNcqYfbSq35kdDndXQM= X-Received: by 2002:a05:6808:1314:b0:3eb:47f9:a7fa with SMTP id 5614622812f47-3ed8e028af9mr27518683b6e.21.1735918498318; Fri, 03 Jan 2025 07:34:58 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a8a:1872:0:b0:577:9519:f64a with HTTP; Fri, 3 Jan 2025 07:34:57 -0800 (PST) In-Reply-To: <20250103135332.7910a008714abaa04d32e5e2@magnetkern.de> References: <20241227205025.1d059f72c7c08d23c9648c26@magnetkern.de> <20241228004009.267f21b78394c934f27f9974@magnetkern.de> <20250103135332.7910a008714abaa04d32e5e2@magnetkern.de> From: "David G. Johnston" Date: Fri, 3 Jan 2025 08:34:57 -0700 Message-ID: Subject: Re: search_path for PL/pgSQL functions partially cached? To: Jan Behrens Cc: "pgsql-general@lists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000739291062acf05e1" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000739291062acf05e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, January 3, 2025, Jan Behrens wrote: > > I would like to know if the above example is correct. It seems overall > bulky, but I haven't found a better way, assuming that it can be > unknown where a particular extension has been installed to. In > particular I feel a bit insecure about where I have to fully qualify, > and where not. See the comments in the code above. Short answer, you cannot looking at a definition and know the answer - whether the code is going to be executed in a sanitized search_path is what matters. Anything that would be executed during pg_restore has to be made safe. Therefore, code that is only ever executed by applications directly can use swarch_path. I=E2=80=99d probably modify the function signature to take search_path as a= second optional argument and then invoke a set search_path within the function. At worse the caller can place current_setting(search_path) as the value of that argument though being explicit would be recommended. David J. --000000000000739291062acf05e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, January 3, 2025, Jan Behrens <jbe-mlist@magnetkern.de> wrote:
I would like to know if the above example is correct. It seems overall
bulky, but I haven't found a better way, assuming that it can be
unknown where a particular extension has been installed to. In
particular I feel a bit insecure about where I have to fully qualify,
and where not. See the comments in the code above.

Short answer, you cannot looking at a definition and know the answe= r - whether the code is going to be executed in a sanitized search_path is = what matters.=C2=A0 Anything that would be executed during pg_restore has t= o be made safe.=C2=A0 Therefore, code that is only ever executed by applica= tions directly can use swarch_path.

I=E2=80=99d pr= obably modify the function signature to take search_path as a second option= al argument and then invoke a set search_path within the function.=C2=A0 At= worse the caller can place current_setting(search_path) as the value of th= at argument though being explicit would be recommended.

David J.

--000000000000739291062acf05e1--