On Tue, Apr 16, 2019 at 04:24:20AM -0500, Eric Hanson wrote:
> On Tue, Apr 16, 2019 at 12:47 AM Noah Misch <noah@leadboat.com> wrote:
> > https://www.postgresql.org/message-id/20180710014308.GA805781@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.GA1485875@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