Re: erroneous restore into pg_catalog schema - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: erroneous restore into pg_catalog schema
Date
Msg-id m2vc5m9g95.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: erroneous restore into pg_catalog schema  (Stephen Frost <sfrost@snowman.net>)
Responses Re: erroneous restore into pg_catalog schema  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> Having a schema that isn't pg_catalog doesn't necessairly mean we need a
> schema per extension.  Just a 'pg_extensions' schema, which is added to
> search_path behind the scenes (just like pg_catalog..) would be better
> than having everything go into pg_catalog.  I'd prefer that we let the
> admins control both where extensions get installed to and what schemas
> are added to the end of the search_path.

That was discussed in the scope of the first extension patch and it took
us about 1 year to conclude not to try to solve search_path at the same
time as extensions. I'm not convinced we've had extensions for long
enough to be able to reach a conclusion already, but I'll friendly watch
that conversation happen again.

My opinion is that a pg_extension schema with a proper and well
documented set of search_path properties would be good to have. A way to
rename it per-database doesn't strike me as that useful as long as we
have ALTER EXTENSION … SET SCHEMA …

The current default schema where to install extensions being "public",
almost anything we do on that front will be an improvement.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Configurable location for extension .control files
Next
From: Dimitri Fontaine
Date:
Subject: Re: Configurable location for extension .control files