multi-install PostgresNode
От | Andrew Dunstan |
---|---|
Тема | multi-install PostgresNode |
Дата | |
Msg-id | a94c74f9-6b71-1957-7973-a734ea3cbef1@dunslane.net обсуждение исходный текст |
Ответы |
Re: multi-install PostgresNode
(Michael Paquier <michael@paquier.xyz>)
Re: multi-install PostgresNode (Daniel Gustafsson <daniel@yesql.se>) |
Список | pgsql-hackers |
I've been giving some thought to $subject. The initial impetus is the promise I made to assist with testing of clients built with NSS against servers built with openssl, and vice versa. I've already generalized the process of saving binaries by the buildfarm client. And we could proceed with a purely bespoke module for testing the SSL components, as we already do for testing cross-version pg_upgrade. But it struck me that it might be better to leverage our existing investment in TAP tests. So I came up with the idea of creating a child module of PostgresNode.pm, which would set the PATH and other variables appropriately at the start of each method and restore them on method exit. So then we could have things like: $openssl_node->start; my $connstr = $openssl_node->connstr; $nss_node->psql($connstr, ...); To use this a TAP test would need to know two (or more) install paths for the various nodes, presumably set in environment variables much as we do now for things like TESTDIR. So for the above example, the TAP test could set things up with: my $openssl_node=PostgresNodePath::get_new_node($ENV{OPENSSL_POSTGRES_INSTALL_PATH},'openssl'); my $nss_node=PostgresNodePath::get_new_node($ENV{NSS_POSTGRES_INSTALL_PATH},'nss'); Other possible uses would be things like cross-version testing of pg_dump (How do we know we haven't broken anything in dumping very old versions?). The proposed module would look something like this: package PostgresNodePath; use strict; use warnings; use parent PostgresNode; use Exporter qw(import); our @EXPORT = qw(get_new_node); sub get_new_node { my $installpath= shift; my $node = PostgresNode::get_new_node(@_); bless $node; # re-bless into current class $node->{_installpath} = $installpath; return $node; } and then for each class method in PostgresNode.pm we'd have an override something like: sub foo { my $node=shift; my $inst = $node->{_installpath}; local %ENV = %ENV; $ENV{PATH} = "$inst/bin:$ENV{PATH}"; $ENV{LD_LIBRARY_PATH} = "$inst/lib:$ENV{LD_LIBRARY_PATH}"; $node->SUPER::foo(@_); } There might be more elegant ways of doing this, but that's what I came up with. My main question is: do we want something like this in the core code (presumably in src/test/perl), or is it not of sufficiently general interest? If it's wanted I'll submit a patch, probably for the March CF, but January if I manage to get my running shoes on. If not, I'll put it in the buildfarm code, but then any TAP tests that want it will likewise need to live there. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления:
Следующее
От: Heikki LinnakangasДата:
Сообщение: Re: Perform COPY FROM encoding conversions in larger chunks