On Fri, Jan 11, 2019 at 02:22:01PM -0500, Robert Haas wrote: > On Sun, Jan 6, 2019 at 10:26 PM Michael Paquier <mich...@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
signature.asc
Description: PGP signature