Changing extension schema fails silently

On 5 July 2011 21:27, Thom Brown <thom@linux.com> wrote:

Hi,

I'm using the latest head and I created the file_fdw extension, then
attempted to change its schema (ALTER EXTENSION file_fdw SET SCHEMA
new_schema.  No error was returned, but it remained in the same schema
(according to pg_extension).

I then dropped the extension and created it again specifying the new
schema, and it is correctly assigned to that schema.

Am I missing something, or does this fail silently?

Correction, the objects which belong to the extension do switch
schema, but the properties of the extension itself indicate the
extension is in a different schema. So rather than not working at
all, it seems that it's just forgotten to update the pg_extension
catalog table.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

From the docs:

Note that unlike most catalogs with a "namespace" column, extnamespace
is not meant to imply that the extension belongs to that schema.
Extension names are never schema-qualified. Rather, extnamespace
indicates the schema that contains most or all of the extension's
objects. If extrelocatable is true, then this schema must in fact
contain all schema-qualifiable objects belonging to the extension.

However, if you look at the source, the function
AlterExtensionNamespace(List *names, const char *newschema) has this
line:

/* Now adjust pg_extension.extnamespace */
extForm->extnamespace = nspOid;

So clearly the catalog column ought to have been updated. I can't
recreate the problem here, and I too am working from git head on the
master branch.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

On 5 July 2011 22:31, Peter Geoghegan <peter@2ndquadrant.com> wrote:

From the docs:

Note that unlike most catalogs with a "namespace" column, extnamespace
is not meant to imply that the extension belongs to that schema.
Extension names are never schema-qualified. Rather, extnamespace
indicates the schema that contains most or all of the extension's
objects. If extrelocatable is true, then this schema must in fact
contain all schema-qualifiable objects belonging to the extension.

However, if you look at the source, the function
AlterExtensionNamespace(List *names, const char *newschema) has this
line:

/* Now adjust pg_extension.extnamespace */
extForm->extnamespace = nspOid;

So clearly the catalog column ought to have been updated. I can't
recreate the problem here, and I too am working from git head on the
master branch.

D'oh, I've discovered the problem. It's my copy of PgAdmin that was
reporting the wrong name. Nothing to see here.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Thom Brown <thom@linux.com> writes:

Correction, the objects which belong to the extension do switch
schema, but the properties of the extension itself indicate the
extension is in a different schema. So rather than not working at
all, it seems that it's just forgotten to update the pg_extension
catalog table.

Really? Works for me.

regards, tom lane

On 5 July 2011 23:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Thom Brown <thom@linux.com> writes:

Correction, the objects which belong to the extension do switch
schema, but the properties of the extension itself indicate the
extension is in a different schema.  So rather than not working at
all, it seems that it's just forgotten to update the pg_extension
catalog table.

Really?  Works for me.

It was a Thom fail.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company