Andres Freund <andres@anarazel.de> writes:
> On 2019-05-21 10:20:57 -0400, Tom Lane wrote:
>> The least invasive way to do that seems to be as attached, building a
>> little knowledge into pg_regress's psql_command() function. Alternatively
>> we could add a "bool quiet" parameter to that function so that callers
>> had to say what to do, but I'm not sure that's an improvement.
> It's not overly pretty, but also not that bad. I was wondering whether
> we could make psql_command accept multiple statements (annoying due to
> argument passing - although I guess we could switch to using numeric
> references to arguments), use putenv to put client_min_messages into
> PGOPTIONS (to finnicky to remove again), have psql_command pass the
> command to psql via stdin (more code needed for pipe setup). So I think
> we can just go with what you're proposing. Although I also could just go
> with always supressing notices in psql_command().
I think it's better to only suppress where we have a reason to expect
a notice; unexpected notices are the kind of thing you want a test
to find.
Another angle on this is that multiple -c switches only work back to
psql 9.6. Before that it only honors the last -c switch, so that this
change has no effect. I'm only proposing that we apply this change
in HEAD, so it would only matter for cross-version-upgrade tests,
and I think that "no effect" should be acceptable in those.
Alternatively we could go with the stdin approach, but as you say,
that seems like it takes more code than this is worth.
regards, tom lane