Re: pgsql: Make VACUUM accept 1 and 0 as a boolean value.
От | Andres Freund |
---|---|
Тема | Re: pgsql: Make VACUUM accept 1 and 0 as a boolean value. |
Дата | |
Msg-id | 20190521160020.wckjt7ggkwzwr4cj@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pgsql: Make VACUUM accept 1 and 0 as a boolean value. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Make VACUUM accept 1 and 0 as a boolean value.
|
Список | pgsql-committers |
Hi, On 2019-05-21 10:20:57 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2019-05-20 20:19:20 -0400, Tom Lane wrote: > >> The other thing I had to do below was to suppress "NOTICE: database > >> "regression" does not exist, skipping". The added createdb is a > >> mighty expensive and grotty way to do that, but I didn't immediately > >> see a better one. > > > Hm. Perhaps we ought to just have pg_regress set client_min_messages to > > something less noisy when running DROP DATABASE? I don't think any > > pg_regress caller benefits from having it. > > 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(). Greetings, Andres Freund
В списке pgsql-committers по дате отправления: