Dimitri Fontaine <dimi...@2ndquadrant.fr> writes: > Tom Lane <t...@sss.pgh.pa.us> writes: >> Right, the basic difficulty here is exactly that in a Makefile that's >> building multiple shlibs, there is no easy way to decide which shlibs go >> with which sql scripts. The existing implementation essentially relies >> on the base name of the sql script matching the base name of the shlib. >> Adding a single-valued shlib property wouldn't improve matters at all.
> 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. 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. 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. 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 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.) Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers