Re: Prevent extension creation in temporary schemas

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Chris Travers <chris(dot)travers(at)adjust(dot)com>
Cc: Chris Travers <chris(dot)travers(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Prevent extension creation in temporary schemas
Date: 2019-03-07 06:20:13
Message-ID: 20190307061703.GH17293@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 06, 2019 at 09:33:55AM +0100, Chris Travers wrote:
> Ok so at present I see three distinct issues here, where maybe three
> different patches over time might be needed.
>
> The issues are:
>
> 1. create extension pgcrypto with schema pg_temp; fails because there is
> no schema actually named pg_temp.

Yes, I agree that being able to accept pg_temp as an alias for the
temporary schema for extensions would be kind of nice. Perhaps one
reason why this has not actually happened is that out user base does
not really have use cases for it though.

> 2. If you work around this, the \dx shows temporary extensions in other
> sessions. This is probably the most minor issue of the three.
> 3. You cannot create the same extension in two different schemas.

I would like to think that it should be possible to create the same
extension linked to a temporary schema in multiple sessions in
parallel, as much as it is possible to create the same extension
across multiple schemas. Both are actually linked as temp schemas as
based on connection slots. This would require some changes in the way
constraints are defined in catalogs for extensions. Perhaps there is
either no demand for it, I don't know.

> But I don't think there is likely to be a lot of user confusion here. It
> is hard enough to install extensions in temporary schemas that those who do
> can be expected to know more that \dx commands.

The patch as it stands does not actually solve the root problem and
makes things a bit confusing, so I am marking it as returned with
feedback. Working on this set of problems may be interesting, though
the efforts necessary to make that may not be worth the actual user
benefits.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rajkumar Raghuwanshi 2019-03-07 06:24:04 Re: [HACKERS] advanced partition matching algorithm for partition-wise join
Previous Message Heikki Linnakangas 2019-03-07 06:15:47 Re: Making all nbtree entries unique by having heap TIDs participate in comparisons