From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
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 03:52:52 |
Message-ID: | 9204.1551412372@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:
> 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.
If you're suggesting that we disable that security restriction
during extension creation, I really can't see how that'd be a
good thing ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2019-03-01 04:38:28 | Re: pg_partition_tree crashes for a non-defined relation |
Previous Message | Tom Lane | 2019-03-01 03:47:06 | Re: 2019-03 Starts Tomorrow |