Re: [PATCH] pg_upgrade: Split off pg_fatal() from pg_log()
От
Marko Tiikkaja
Тема
Re: [PATCH] pg_upgrade: Split off pg_fatal() from pg_log()
Дата
Msg-id
5235E005.7070601@joh.to
Ответ на
[PATCH] pg_upgrade: Split off pg_fatal() from pg_log() (Peter Eisentraut)
Список
Дерево обсуждения
[PATCH] pg_upgrade: Split off pg_fatal() from pg_log() Peter Eisentraut <peter_e@gmx.net>
Re: [PATCH] pg_upgrade: Split off pg_fatal() from
pg_log() Bruce Momjian <bruce@momjian.us>
Re: [PATCH] pg_upgrade: Split off pg_fatal() from pg_log() Marko Tiikkaja <marko@joh.to>
Re: [PATCH] pg_upgrade: Split off pg_fatal() from pg_log() Peter Eisentraut <peter_e@gmx.net>
Re: [PATCH] pg_upgrade: Split off pg_fatal() from pg_log() Robert Haas <robertmhaas@gmail.com>
Hi Peter, On 2013-09-13 04:50, Peter Eisentraut wrote: > The experiences with elog() and ereport() have shown that having one > function that can return or not depending on some log level parameter > isn't a good idea when you want to communicate well with the compiler. > In pg_upgrade, there is a similar case with the pg_log() function. > Since that isn't a public API, I'm proposing to change it and introduce > a separate function pg_fatal() for those cases where the calls don't > return. I think the reasoning behind this patch is sound. However, I would like to raise a couple of small questions: 1) Is there a reason for the fmt string not being const char*? You changed it for pg_log_v(), but not for pg_log() and pg_fatal(). 2) Allowing PG_FATAL to be passed to pg_log() seems weird, but I don't feel strongly about that. Other than that, the patch looks good to me. Regards, Marko Tiikkaja
В списке pgsql-hackers по дате отправления