Re: TAP testing for psql's tab completion code - Mailing list pgsql-hackers

From Tom Lane
Subject Re: TAP testing for psql's tab completion code
Date
Msg-id 30270.1577641991@sss.pgh.pa.us
Whole thread Raw
In response to Re: TAP testing for psql's tab completion code  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: TAP testing for psql's tab completion code  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> I've looked at your PoC implementation:

> I'm not fan of relying on the configure stuff ("with_readline"), in my 
> Expect version I tested if history capabilities are available from psql 
> itself.

No, I disagree with that.  If configure thinks it built with readline,
and then the actual binary acts like it doesn't have readline, that's
a bug that we'd like the tests to detect.  We don't want the test
silently deciding that things are OK if the first thing it tries
doesn't work.  (For comparison, the SSL tests are also enabled by
configure's opinion not some other way -- I was mostly copying how
that works.)

> For the psql coverage patch, I was more ambitious and needed less 
> assumption about the configuration, I only forced -X.

I mainly just duplicated the environment set up by PostgresNode::psql
as much as it seemed reasonable to.  The -At options are kind of
irrelevant for what we're going to test here, probably, but why not
keep the default behavior the same?  I did drop -q since that
suppresses prompting, and we probably want to test prompt.c using
this infrastructure.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: [PATCH] Increase the maximum value track_activity_query_size
Next
From: Jeff Janes
Date:
Subject: Re: vacuum verbose detail logs are unclear (show debug lines at*start* of each stage?)