Re: [HACKERS] [PATCH] pg_upgrade: Split off pg_fatal() from pg_log()

2013-10-09 Thread Robert Haas
On Tue, Oct 1, 2013 at 9:33 PM, Peter Eisentraut wrote: > On Sun, 2013-09-15 at 18:27 +0200, Marko Tiikkaja wrote: >> 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 c

Re: [HACKERS] [PATCH] pg_upgrade: Split off pg_fatal() from pg_log()

2013-10-01 Thread Peter Eisentraut
On Sun, 2013-09-15 at 18:27 +0200, Marko Tiikkaja wrote: > 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()

Re: [HACKERS] [PATCH] pg_upgrade: Split off pg_fatal() from pg_log()

2013-09-26 Thread Bruce Momjian
On Thu, Sep 12, 2013 at 10:50:42PM -0400, 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,

Re: [HACKERS] [PATCH] pg_upgrade: Split off pg_fatal() from pg_log()

2013-09-15 Thread Marko Tiikkaja
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 simil