Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
От | Tom Lane |
---|---|
Тема | Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII |
Дата | |
Msg-id | 3016.1378494339@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII (Greg Stark <stark@mit.edu>) |
Ответы |
Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
|
Список | pgsql-hackers |
Greg Stark <stark@mit.edu> writes: > What would be nicer would be to display the C define, EINVAL, EPERM, etc. > Afaik there's no portable way to do that though. I suppose we could just > have a small array or hash table of all the errors we know about and look > it up. Yeah, I was just thinking the same thing. We could do switch (errno){ case EINVAL: str = "EINVAL"; break; case ENOENT: str = "ENOENT"; break; ... #ifdef EFOOBAR case EFOOBAR: str = "EFOOBAR"; break; #endif ... for all the common or even less-common names, and only fall back on printing a numeric value if it's something really unusual. But I still maintain that we should only do this if we can't get a useful string out of strerror(). There isn't any way to cram this information into the current usage of %m without doing damage to the readability and translatability of the string. Our style & translatability guidelines specifically recommend against assembling messages out of fragments, and also against sticking in parenthetical additions. I suppose we could think about inventing another error field rather than damaging the readability of the primary message string, ie teach elog that if %m is used it should emit an additional line along the lines ofERRNO: EINVAL However the cost of adding a new column to CSV log format might exceed its value. regards, tom lane
В списке pgsql-hackers по дате отправления: