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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
