| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | 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: | 2021-04-14 02:08:27 |
| Message-ID: | 20210414020827.GA1232417@rfd.leadboat.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 13, 2021 at 06:26:34PM -0400, Tom Lane wrote:
> Attached are some draft patches to convert almost all of the
> contrib modules' SQL functions to use SQL-standard function bodies.
> The point of this is to remove the residual search_path security
> hazards that we couldn't fix in commits 7eeb1d986 et al. Since
> a SQL-style function body is fully parsed at creation time,
> its object references are not subject to capture by the run-time
> search path.
Are there any inexact matches in those function/operator calls? Will that
matter more or less than it does today?
> However I think we may still need an assumption that earthdistance
> and cube are in the same schema --- any comments on that?
That part doesn't change, indeed.
> I'd like to propose squeezing these changes into v14, even though
> we're past feature freeze. Reason one is that this is less a
> new feature than a security fix; reason two is that this provides
> some non-artificial test coverage for the SQL-function-body feature.
Dogfooding like this is good. What about the SQL-language functions that
initdb creates?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2021-04-14 02:21:55 | Re: Replication slot stats misgivings |
| Previous Message | vignesh C | 2021-04-14 01:50:09 | Re: Replication slot stats misgivings |