I've run into a small infelicity that was introduced by our recent round of redesign of the extensions feature. Specifically, if we have an installation script that is named like hstore-1.0.sql.in, then what pgxs.mk will substitute for MODULE_PATHNAME in it is "$libdir/hstore-1.0" ... not exactly what's wanted. This is because the transformation rule depends on $*, ie the base name of the input file.
There are a number of things we could do about this, each with some upsides and downsides: 1. Forget about using MODULE_PATHNAME, and just start hardwiring "$libdir/shlib-name" into install scripts. A small upside is we'd not need the .sql.in-to-.sql build step anymore. The downside is that it's kind of nice that the sql scripts don't need to know the shlib name --- that certainly simplifies copying-and-pasting example functions. 2. Change the pgxs.mk rule to use $(MODULE_big)$(MODULES) instead of $* (as I suspect it originally did, given the conditional around it). This would work for makefiles that use $(MODULE_big) or use $(MODULES) to build just a single shlib. In those that build multiple shlibs (currently only contrib/spi), we'd still have to fall back to hardwiring "$libdir/shlib-name" into the install scripts. Upside: works without changes in simple cases. Downside: breaks for multiple output modules, and ugly as sin anyway. 3. Change the pgxs.mk rule to strip $* down to whatever's before the first dash. The downside of this is that we'd have to restrict extensions to not have names including dash, a restriction not being made presently. On the other hand, we may well have to enforce such a restriction anyway in order to get pg_available_extensions to make sense of the directory contents. Another point is that changing the rule would potentially break old-style non-extension modules that use dashes in their names. We could work around that by making the rule behavior conditional on whether EXTENSION is defined, which is kinda ugly but probably worth doing for backwards compatibility's sake. On balance #3 seems the least bad, but I wonder if anyone sees this choice differently or has another solution that I didn't think of. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers