From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Subject: | Re: Converting contrib SQL functions to new style |
Date: | 2024-11-06 01:05:16 |
Message-ID: | 3133933.1730855116@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> I was wondering what was going on here, and this patch comes down to
> switching all these definitions from that:
> CREATE FUNCTION lo_oid(lo) RETURNS pg_catalog.oid AS
> 'SELECT $1::pg_catalog.oid' LANGUAGE SQL STRICT IMMUTABLE PARALLEL SAFE;
> To that:
> +CREATE OR REPLACE FUNCTION lo_oid(lo) RETURNS pg_catalog.oid
> +LANGUAGE SQL STRICT IMMUTABLE PARALLEL SAFE
> +RETURN (SELECT $1::pg_catalog.oid);
Right.
> This makes the executions more robust run-time search_path checks. Is
> that something that should be considered for a backpatch, actually?
No, I don't think so. For one thing, it would not help existing
installations unless they issue "ALTER EXTENSION UPDATE", which
people are not likely to do in a minor update. But also, we don't
know of live attacks against these functions with their current
definitions, so I don't think this is urgent.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2024-11-06 02:04:15 | Re: Pgoutput not capturing the generated columns |
Previous Message | Michael Paquier | 2024-11-06 00:52:21 | Re: define pg_structiszero(addr, s, r) |