make check For Extensions
Hackers,
Andres said during the unconference last month that there was a way to get `make check` to work with PGXS. The idea is that it would initialize a temporary cluster, start it on an open port, install an extension, and run the extension's test suite. I think the pg_regress --temp-install, maybe? I poked through the PGXS makefiles, and although it looks like there *might* be something like this for in-core contrib extensions, but not for externally-distributed extensions.
Is there something I could add to my extension Makefiles so that `make check` or `make test` will do a pre-install test on a temporary cluster?
Thanks,
David
Andres said during the unconference last month that there was a way to
get `make check` to work with PGXS. The idea is that it would initialize
a temporary cluster, start it on an open port, install an extension, and
run the extension's test suite. I think the pg_regress --temp-install,
maybe? I poked through the PGXS makefiles, and although it looks like
there *might* be something like this for in-core contrib extensions, but
not for externally-distributed extensions.Is there something I could add to my extension Makefiles so that `make
check` or `make test` will do a pre-install test on a temporary cluster?
My 0.02ￜ: It is expected to work, more or less, see the end of
http://www.postgresql.org/docs/9.3/static/extend-pgxs.html
It invokes "psql" which is expected to work directly. Note that there is
no temporary installation, it is tested against the installed and running
postgres. Maybe having the ability to create a temporary installation, as
you suggest, would be a nice extension.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jun 12, 2014, at 11:28 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
My 0.02€: It is expected to work, more or less, see the end of
That says:
“The scripts listed in the REGRESS variable are used for regression testing of your module, which can be invoked by make installcheck after doing make install. For this to work you must have a running PostgreSQL server.”
That does not mean that it starts a new cluster on a port. It means it will test it against an existing cluster after you have installed into that cluster.
It invokes "psql" which is expected to work directly. Note that there is no temporary installation, it is tested against the installed and running postgres. Maybe having the ability to create a temporary installation, as you suggest, would be a nice extension.
Yes, that’s what I would like, so I could test *before* installing.
Best,
David
That does not mean that it starts a new cluster on a port. It means it
will test it against an existing cluster after you have installed into
that cluster.
Yes, that is what I was saying.
It invokes "psql" which is expected to work directly. Note that there
is no temporary installation, it is tested against the installed and
running postgres. Maybe having the ability to create a temporary
installation, as you suggest, would be a nice extension.Yes, that�s what I would like, so I could test *before* installing.
I would suggest to add that to https://wiki.postgresql.org/wiki/Todo.
I may look into it when I have time, over the summer. The key point is
that there is no need for a temporary installation, but only of a
temporary cluster, and to trick this cluster into loading the uninstalled
extension, maybe by playing with dynamic_library_path in the temporary
cluster.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jun 12, 2014, at 11:40 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
I would suggest to add that to https://wiki.postgresql.org/wiki/Todo.
I may look into it when I have time, over the summer. The key point is that there is no need for a temporary installation, but only of a temporary cluster, and to trick this cluster into loading the uninstalled extension, maybe by playing with dynamic_library_path in the temporary cluster.
The temporary cluster will be in a temporarty `initdb`ed directory, no? If so, you can just install the extension there.
Best,
David
I would suggest to add that to https://wiki.postgresql.org/wiki/Todo.
I may look into it when I have time, over the summer. The key point is
that there is no need for a temporary installation, but only of a
temporary cluster, and to trick this cluster into loading the
uninstalled extension, maybe by playing with dynamic_library_path in
the temporary cluster.The temporary cluster will be in a temporarty `initdb`ed directory, no?
Yep.
If so, you can just install the extension there.
I'm not sure the extension is sought for in the cluster (ie the database
data directory). If you do "make install" the shared object is installed
in some /usr/lib/postgresql/... directory (under unix), and it is loaded
from there, but I understood that you wanted to test WITHOUT installing
against the current postgresql.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jun 15, 2014, at 12:25 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
I'm not sure the extension is sought for in the cluster (ie the database data directory). If you do "make install" the shared object is installed in some /usr/lib/postgresql/... directory (under unix), and it is loaded from there, but I understood that you wanted to test WITHOUT installing against the current postgresql.
I would assume there is a way to do it with a path…it’ just a SMOP, of course.
D