Re: pg_croak, or something like it?
От | Robert Haas |
---|---|
Тема | Re: pg_croak, or something like it? |
Дата | |
Msg-id | CA+TgmoYjM-6Zikp5+xLaNM_AbqsxUE7V+0HMWjk6WFWdbFwoww@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_croak, or something like it? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_croak, or something like it?
|
Список | pgsql-hackers |
On Mon, Jan 27, 2020 at 10:50 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > So? elog() is just a specific degenerate case of ereport(). If we have > a way to implement ereport() on frontend side then we can surely do > elog() too. I suppose that's true. > What it sounds to me like you want to do is implement (some equivalent of) > elog() but not ereport() for this environment. I'm going to resist that > pretty strongly, because I think it will lead directly to abuse of elog() > for user-facing errors, with a consequent degradation of the user > experience when that code executes on backend side. I do not believe > that there are no user-facing error cases in the JSON parser, for > example; much less that we'll never introduce any in future. You clearly haven't read the thread on this topic, or at least not very carefully. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: