On Tue, Apr 16, 2019 at 04:24:20AM -0500, Eric Hanson wrote: > On Tue, Apr 16, 2019 at 12:47 AM Noah Misch <n...@leadboat.com> wrote: > > https://www.postgresql.org/message-id/20180710014308.ga805...@rfd.leadboat.com > > > > The @DEPNAME_schema@ thing was trivial to implement, but I shelved it. > > I'm attaching the proof of concept, for your information.
> Why shelved? I like it. You said you lean toward 2b in the link above, > but there is no 2b :-) but 1b was this option, which maybe you meant? (2) is a mutation of (1), so (2b) exists by mutating (1b) according to the description of (2). In other words, (2b) would be this: Drop relocatable=true from extensions that have cause to do so (by adding a new version number and versioned control file): cube, earthdistance, pageinspect, pg_freespacemap, xml2. Do likewise for others as needed in the future. To relocate an affected extension, drop and recreate it. Warn about relocatable=true in non-core extensions. Expand @DEPNAME_schema@ in extension SQL files. Use @cube_schema@ to refer to the right objects. I shelved it because thread http://postgr.es/m/flat/20180830070609.ga1485...@rfd.leadboat.com did not accept it as a solution for contrib/ extensions. If it's not good enough for contrib/, it's not good enough for this problem space. > The other approach would be to have each extension be in it's own schema, > whose name is fixed for life. Then there are no collisions and no > ambiguity about their location. I don't use NPM but was just reading > about how they converted their package namespace from a single global > namespace with I think it was 30k packages in it, > to @organization/packagename. I don't know how folks would feel about a > central namespace registry, I don't love the idea if we can find a way > around it, but would settle for it if there's no better solution. Either > that or use a UUID as the schema name. Truly hideous. But it seems like > your approach above with just dynamically looking up the extension's schema > as a variable would solve everything. That's like how C/C++/Java identifiers work, turning each @DEPNAME_schema@ into a constant. If we were starting from scratch, that's attractive. Unfortunately, folks have applications that expect to use e.g. public.earth(). We'd need a big benefit to justify obligating those users to migrate. If we had @DEPNAME_schema@, communities of users could decide to adopt a local convention of a fixed schema per extension. Other communities of users, particularly those with substantial stable code, could retain their current schema usage patterns. Thanks, nm
