make installcheck doesn't work under mingw64

[robe2]

Is it just me or does make installcheck just not finished yet?

I do make installcheck

after make install, and it creates the contrib_regression database, but it fails to install the extension and ends with error:

(using postmaster on localhost, port 5444) ============== dropping database "contrib_regression" ============== DROP DATABASE ============== creating database "contrib_regression" ============== CREATE DATABASE ALTER DATABASE ============== running regression test queries ============== test ogr_fdw ... The system cannot find the path specified.

If I go into the the contrib_regression database it created and then run

CREATE EXTENSION ogr_fdw;

that works fine so I assume I have all the dependencies installed it needs.

[pramsey]

It's not you, there's nothing there yet. I think I'll add some tests that connect a database back to itself, but I haven't done anything yet (patches happily accepted)

[robe2]

Okay I'll see if I can come up with something.

I don't think having an fdw that connects back to itself is very interesting nor guaranteed to work. You'd ideally want to test drivers that are always available like ESRI shapefile or OpenGDB.

For example, I don't build gdal with postgresl dependency so it would fail on mine right away. Probably better to just have a variable that can be overwritten that points to an fdw folder of files, but guesses at the path. Like something that resolves to your git packaged data folder?

I say it needs to be overwritten because on my windows my FDW Server path would look something like C:/projects/sources/pgsql_ogr_fdw/data

which is different than what I would normally get via my mingw path /sources/pgsql_ogr_fdw/data

[pramsey]

The trouble w/ shapefile/fgdb is getting them somewhere the database is guaranteed to be able to read them, because there's no guarantee the postgres process is going to be able to read them from where you compiled them (most linuxes and osx come w/ user accounts non-readable by other user accounts (like postgres))

[robe2]

That's partly why I was thinking you specify a folder variable that can be overwritten. I guess that could also be an option to copy the files to that folder so user can specify a folder the postgres process has access to, or is that too hard to ochestrate? Sorry if I'm making this so complicated :(

[pramsey]

Right now my makefile is blissfully uncomplicated. Hoping not to replicate the postgis build situation too early in the life cycle. :) But yes, a test set is needed sooner than later, one way or another.

[robe2]

The file_text_array fdw I use heavily installchecks fine on my machine. Was thinking of using the same approach -- does this compile and installcheck fine under your Mac?

https://github.com/adunstan/file_text_array_fdw

I do have to make sure to do export USE_PGXS=1 otherwise it assumes I am building as part of the PostgreSQL tree and then doesn't work. My general compile steps are

    export PGPORT=5444
    export PGUSER=postgres
    git clone -b REL9_4_STABLE https://github.com/adunstan/file_text_array_fdw.git file_text_array_fdw_94
    cd file_text_array_fdw_94
    export USE_PGXS=1
    make install
    make installcheck

[pramsey]

My personal environment is setup so that it’s globally readable and probably yours is too, but that’s not a fair expectation, necessarily. It looks like pg_regress does a replace of @abs_srcdir@ automatically. 

                        replace_string(line, "@abs_srcdir@", inputdir);                         replace_string(line, "@abs_builddir@", outputdir);                         replace_string(line, "@testtablespace@", testtablespace);                         replace_string(line, "@libdir@", dlpath);                         replace_string(line, "@DLSUFFIX@", DLSUFFIX);

So as a first approximation, following the example in file fdw wouldn’t be a bad thing to do.

P.