On Fri, Jan 11, 2019 at 02:22:01PM -0500, Robert Haas wrote:
> On Sun, Jan 6, 2019 at 10:26 PM Michael Paquier <michael@paquier.xyz> wrote:
>> This combination makes no actual sense, so wouldn't it be better to
>> restrict the case?
>
> Hmm. What exactly doesn't make sense about it?
In my mind, extensions are designed to be database-wide objects which
are visible to all sessions. Perhaps I am just confused by what I
think they should be, and I can see no trace on the archives about
concept of extensions + temp schema as base (adding Dimitri in CC if
he has an idea). I can see as well that there have been stuff about
using temporary objects in extension script though ("Fix bugs with
temporary or transient tables used in extension scripts" in release
notes of 9.1).
For most of extensions, this can randomly finish with strange error
messages, say that:
=# create extension file_fdw with schema pg_temp_3;
ERROR: 42883: function file_fdw_handler() does not exist
LOCATION: LookupFuncName, parse_func.c:2088
There are cases where the extension can be created:
=# create extension pgcrypto with schema pg_temp_3;
CREATE EXTENSION
Time: 36.567 ms
=# \dx pgcrypto
List of installed extensions
Name | Version | Schema | Description
----------+---------+-----------+-------------------------
pgcrypto | 1.3 | pg_temp_3 | cryptographic functions
(1 row)
Then the extension is showing up as beginning to be present for other
users. I am mainly wondering if this case has actually been thought
about in the past or discussed, and what to do about that and if we
need to do something. Temporary extensions can exist as long as the
extension script does not include for example REVOKE queries on the
functions it creates (which should actually work?), and there is a
separate thread about restraining 2PC when touching the temporary
namespace for the creation of many objects, and extensions are one
case discussed. Still the concept looks a bit wider, so I spawned a
separate thread.
--
Michael
