Thread: [patch] extensions_path GUC
One problem we have with PostGIS is you cannot test an extension unless you have access to the system extension dir. The following patch tries to address that by allowing to specify a per-cluster extension path via an "extensions_path" GUC. It is more a request-for-comments rather than a ready patch, as I hadn't considered all use cases like upgrades of already-loaded extensions and the possibility ot have a list of directories to seek for extensions. Anyway, patch is attached. --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html
Attachment
On 10/23/2015 01:33 PM, Sandro Santilli wrote: > One problem we have with PostGIS is you cannot test an extension > unless you have access to the system extension dir. > > The following patch tries to address that by allowing to specify > a per-cluster extension path via an "extensions_path" GUC. > > It is more a request-for-comments rather than a ready patch, as > I hadn't considered all use cases like upgrades of already-loaded > extensions and the possibility ot have a list of directories to > seek for extensions. This was discussed a while ago already, see http://www.postgresql.org/message-id/51AE0845.8010600@ocharles.org.uk. In short, I don't think just setting extensions_path is enough or desirable, but I would welcome a patch that makes "make check" work for extensions, by creating a temporary installation. - Heikki
23.10.2015, 13:33, Sandro Santilli kirjoitti: > One problem we have with PostGIS is you cannot test an extension > unless you have access to the system extension dir. > > The following patch tries to address that by allowing to specify > a per-cluster extension path via an "extensions_path" GUC. > > It is more a request-for-comments rather than a ready patch, as > I hadn't considered all use cases like upgrades of already-loaded > extensions and the possibility ot have a list of directories to > seek for extensions. > > Anyway, patch is attached. This would be very useful. I proposed this previously in February, but that implementation (almost identical to yours) was rejected. https://commitfest.postgresql.org/5/170/ http://www.postgresql.org/message-id/54E3C31F.8010703@ohmu.fi Both of these implementations miss a way to override the path for extension .so files. / Oskari
On Fri, Oct 23, 2015 at 7:46 PM, Heikki Linnakangas wrote: > On 10/23/2015 01:33 PM, Sandro Santilli wrote: > In short, I don't think just setting extensions_path is enough or desirable, > but I would welcome a patch that makes "make check" work for extensions, by > creating a temporary installation. Isn't that the existing EXTRA_INSTALL? -- Michael
On 10/23/2015 02:59 PM, Michael Paquier wrote: > On Fri, Oct 23, 2015 at 7:46 PM, Heikki Linnakangas wrote: >> On 10/23/2015 01:33 PM, Sandro Santilli wrote: >> In short, I don't think just setting extensions_path is enough or desirable, >> but I would welcome a patch that makes "make check" work for extensions, by >> creating a temporary installation. > > Isn't that the existing EXTRA_INSTALL? No. The problem is that "make check" doesn't work extensions built outside the server source tree. You get an error: "make check" is not supported. Do "make install", then "make installcheck" instead. - Heikki
On 10/23/15 11:02 AM, Heikki Linnakangas wrote: > On 10/23/2015 02:59 PM, Michael Paquier wrote: >> On Fri, Oct 23, 2015 at 7:46 PM, Heikki Linnakangas wrote: >>> On 10/23/2015 01:33 PM, Sandro Santilli wrote: >>> In short, I don't think just setting extensions_path is enough or >>> desirable, >>> but I would welcome a patch that makes "make check" work for >>> extensions, by >>> creating a temporary installation. >> >> Isn't that the existing EXTRA_INSTALL? > > No. The problem is that "make check" doesn't work extensions built > outside the server source tree. You get an error: > > "make check" is not supported. > Do "make install", then "make installcheck" instead. I would love it if make check worked. make installcheck adds extra effort to extension develoopment, not to mention leaving your actual install in a less than pristine state. Possibly related to this... I'd also like to have other options for running unit tests, besides pg_regress. I looked at it briefly and the big PITA about doing it was having to manage the temporary database (and ideally temporary cluster). If standing those up was separated from pg_regress it would make it a lot easier for someone to customize how testing works under PGXS. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
On Oct 23, 2015, at 9:26 AM, Jim Nasby <Jim.Nasby@BlueTreble.com> wrote: > I would love it if make check worked. make installcheck adds extra effort to extension develoopment, not to mention leavingyour actual install in a less than pristine state. I’ve wanted this for a long time. I think it would have to create a temporary cluster, fire up a server, install the extension(s),run the tests, shut down the server and delete the cluster. > Possibly related to this... I'd also like to have other options for running unit tests, besides pg_regress. I looked atit briefly and the big PITA about doing it was having to manage the temporary database (and ideally temporary cluster).If standing those up was separated from pg_regress it would make it a lot easier for someone to customize how testingworks under PGXS. Right, then pg_regress could just be the default test framework. Dvaid