|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
|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|