Re: Badly designed error reporting code in controldata_utils.c
От | Michael Paquier |
---|---|
Тема | Re: Badly designed error reporting code in controldata_utils.c |
Дата | |
Msg-id | CAB7nPqS0zX6L3DoGYTi4_7TMXVzjqSGswMRRcXtzpsJe=aC3kg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Badly designed error reporting code in controldata_utils.c (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Tue, Mar 8, 2016 at 1:51 PM, Andres Freund <andres@anarazel.de> wrote: > On 2016-03-08 13:45:25 +0900, Michael Paquier wrote: >> On Mon, Mar 7, 2016 at 10:26 AM, Andres Freund <andres@anarazel.de> wrote: >> > FWIW I'm considering implementing elog/ereport properly for the >> > frontend. We've grown several hacks around that not being present, and >> > I think those by now have a higher aggregate complexity than a proper >> > implementation would have. >> >> That would be handy. And this is are going to need something like >> callbacks to allow frontend applications how to apply elevel. Take for >> example pg_rewind, it has an interface with DEBUG and PROGRESS level >> directly embedded with FATAL controlled by user-defined options. > > What does "directly embedded with FATAL" mean? Incorrect words. I just mean that there is a central code path used by DEBUG and FATAL in this case, and DEBUG is controlled by a user-side switch, meaning that if we want to get into something aimed at being used by any in-core or community frontend clients, we are going to need something carefully designed. -- Michael
В списке pgsql-hackers по дате отправления: