Tom Lane <t...@sss.pgh.pa.us> writes: > I'm with Alvaro on this. If we're going to have an ALTER EXTENSION SET > SCHEMA operation, then extensions must have a well-defined schema > property, and it would be good if that connection were explicitly > represented in the catalogs. Digging stuff out of pg_depend sucks; > we have to do it in some other cases where we didn't foresee the > connection in advance, but we can see it well enough here.
Ok. So an extension using more than one schema is out, right? Not that I can see a strong use case, just thinking out loud. Also, do we keep the current notation or change it, or add to it: CREATE EXTENSION foo WITH SCHEMA utils; CREATE EXTENSION utils.foo; I guess if you schema qualify the extension's name we could use that as the schema name, but remember that the control file name would then be different from the (qualified and given) extension's name. Surely we would not try to find the utils.foo.control file, right? The schema name is also used as a placeholder in the extension SQL script, so it is somewhat weird to have it in the extension's name. > BTW, I'm not even 100% convinced that the schema shouldn't be part of > the extension's name, if we're going to make it work like this. Is > there a reason I shouldn't be able to have both public.myextension > and testing.myextension? If we're constraining all the objects owned by > the extension to live in a single schema, this seems perfectly feasible. Are you proposing that an extension object is schema qualified? Would we lower creating extension privileges to database owners, too, rather than only superusers? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
