Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@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 likeextension--version.controlextension--version.sqlextension--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