Re: Odd usage of errmsg_internal in bufmgr.c
| От | Andres Freund |
|---|---|
| Тема | Re: Odd usage of errmsg_internal in bufmgr.c |
| Дата | |
| Msg-id | aY4Jqm1LcanN7PgH@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | Re: Odd usage of errmsg_internal in bufmgr.c (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Odd usage of errmsg_internal in bufmgr.c
|
| Список | pgsql-hackers |
Hi, On 2026-02-11 22:13:24 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2026-02-11 20:34:50 -0500, Tom Lane wrote: > >> I agree that that isn't great code, but what I don't like about it > >> is the separation between where the format string is defined and > >> where it is used. It'd be very easy for the %-escapes to get out of > >> sync with the types of the actual parameters, and if they did, the > >> compiler would not warn you. I think we ought to try to recast this > >> into the normal usage pattern where the format is literal within the > >> errmsg call. I see the comment about avoiding code duplication, but > >> to my mind this is a terrible solution. > > > The amount of code duplication it avoids is rather substantial. > > Really? By my count it's strictly fewer lines to do it the > straightforward way. Yes, I'm counting removal of the comments > defending doing it in the convoluted way, but on the other hand the > attached patch adds quite a few extra line breaks for readability, > and still comes out 4 lines shorter. Not to mention less fragile. > I do not see a reason why the existing code is good. I think the code after the proposed change is considerably harder to read. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: