Tom Lane <t...@sss.pgh.pa.us> writes: >> My take here is to way that in this case, the current (9.1) way to deal >> with the situation is to have multiple extensions when you have multiple >> shlibs. After all we know that multiple extensions from the same >> Makefile works, thanks to contrib/spi (I mean extension/spi). > > But contrib/spi is exactly the case where it *won't* work. We need to > somehow figure out that $libdir/autoinc is what to substitute in > autoinc-1.0.sql, $libdir/insert_username in insert_username-1.0.sql, > etc.
Indeed. That's why I'm proposing to have that setup in the control file, which is per extension, rather than in the common Makefile. > Also, I've been looking at the pg_available_extensions issue a bit. > I don't yet have a proposal for exactly how we ought to redefine it, > but I did notice that the existing code is terribly confused by > secondary control files: it doesn't realize that they're not primary > control files, so you get e.g. hstore and hstore-1.0 as separate > listings. I'd think that's it's a good idea if dealt with "correctly" because now that ALTER EXTENSION UPDATE can deal with more than one target VERSION I expect the view to show each available update here. If possible adding the "update chain sequence" information as computed in the code would be great. Because we can't ask people to figure that out all by themselves, the best way to check your upgrading setup is fine would be to run SELECT * FROM pg_available_extensions; and read the result. > We could possibly work around that by giving secondary control files a > different extension, but I'm becoming more and more convinced that it's > just a bad idea to have a file naming rule in which it's ambiguous where > the extension name stops and the version name starts. Agreed. > I did think of another idea besides forbidding dash in extension names: > what if we use double dash as the name/version separator, ie the naming > conventions are like > extension--version.control > extension--version.sql > extension--oldversion-newversion.sql Yeah, something like that would work, so would maybe using ':' and forbidding one-letter extension names, but I'm not in a position to check that this won't confuse the windows we support too much. I see about no downside to the double dash proposal, that said. > Then we'd only have to forbid double dash in extension names, which > seems unlikely to be a problem for anybody. (I think we might also have > to forbid empty version names to make this bulletproof, but that doesn't > bother me much either.) Those look like sanity checks more than anything else, I'd welcome us having them. 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
