| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Sergei Kornilov <sk(at)zsrv(dot)org>, "Kuroda, Hayato" <kuroda(dot)hayato(at)jp(dot)fujitsu(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Chris Travers <chris(dot)travers(at)adjust(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "dimitri(at)citusdata(dot)com" <dimitri(at)citusdata(dot)com> |
| Subject: | Re: Prevent extension creation in temporary schemas |
| Date: | 2019-03-01 02:43:04 |
| Message-ID: | 20190301024304.GF1348@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 28, 2019 at 10:13:17AM -0500, Tom Lane wrote:
> Yeah, I think it's just because we won't search the pg_temp schema
> for function or operator names, unless the calling SQL command
> explicitly writes "pg_temp.foo(...)" or equivalent. That's an
> ancient security decision, which we're unlikely to undo. It
> certainly puts a crimp in the usefulness of putting extensions into
> pg_temp, but I don't think it totally destroys the usefulness.
> You could still use an extension to package, say, the definitions
> of a bunch of temp tables and views that you need to create often.
Even with that, it should still be possible to enforce search_path
within the extension script to allow such objects to be created
correctly, no? That would be a bit hacky, still for the purpose of
temp object handling that looks kind of enough to live with when
creating an extension.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-03-01 02:48:16 | Re: 2019-03 Starts Tomorrow |
| Previous Message | Michael Paquier | 2019-03-01 02:33:38 | Tighten error control for OpenTransientFile/CloseTransientFile |