On Fri, 22 Jan 2016 16:36:15 -0300
Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> You're editing the expected file for the libpq-regress thingy, but you
> haven't added any new lines to test the new capability. I think it'd
> be good to add some there. (I already said this earlier in the
> thread; is there any reason you ignored it the first time?)
I seriously doubt that this program can be used to test new
capabilities.
All it does, it calls PQconninfoParse and than examines some fields of
PGconn structure.
The only reason I've to modify expected output is that I changed usage
of one of these field, and keep there comma-separated list of host:port
pairs instead of just hostname.
Thus contents this field after parsing of some existing URIs is
changed, while semantic of URIs is same.
If I add some new uris, than only thing I can test is that comma is
properly copied from the URI to this field. And may be that some syntax
errors are properly detected.
> If the test program requires improvement to handle the new stuff,
> let's do that.
The only improvement I can think of, is to examine list of the addrinfo
structures into which host list is eventually parsed. But it is quite
problematic, because it depends on many factors which are outside of
our control.
It stores addresses resolved via OS's name resolver.
For example, if we specify 'localhost' there it can be parsed into one
or to records, depending on presence of IPv6 support.
If we use some other hostname here, we'll rely on internet connectivity
and DNS system. And we cannot ensure that any name to IP mapping will
persist for a long enough time.
So, I think that new functionality need other approach for testing.
There should be test of real connection to real temporary cluster.
Probably, based on Perl TAP framework which is actively used in the
Postgres recently.
>
-- Victor Wagner <vitus@wagner.pp.ru>