Re: Bug with specific-schema extensions

On 4/19/15 5:08 PM, Tom Lane wrote:
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
>> CREATE EXTENSION creates the variant schema for me, but it leaves it
>> behind when I drop the extension. I assume this is a bug and not by design?
>
> No, it's intentional. If you want the schema to be considered part of the
> extension, then create it within the extension.

Throws an exception since the schema now exists (see below).

> We could have made this case fail, rather than auto-create the containing
> schema. That would have been more consistent but probably less useful,
> so we didn't.

It seems like a POLA violation. You start with no schema, CREATE
EXTENSION, DROP EXTENSION, and magically there's this schema left over.

If we're going to magically create the schema (which at least for a
fully non-relocatable extension is fine), then I think we should also
mark the schema as being part of the extension. I'd even argue this is a
bug and should be backpatched, but if people object to that we should at
least change the behavior going forward.

As a refresher, the docs say this about fully non-relocatable extensions:

"If the extension does not support relocation at all, set relocatable =
false in its control file, and also set schema to the name of the
intended target schema. This will prevent use of the SCHEMA option of
CREATE EXTENSION, unless it specifies the same schema named in the
control file. This choice is typically necessary if the extension
contains internal assumptions about schema names that can't be replaced
by uses of @extschema(at)(dot) The @extschema@ substitution mechanism is
available in this case too, although it is of limited use since the
schema name is determined by the control file."
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com