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,

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

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
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.)


                        regards, tom lane

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to