Jeff Davis <pgsql@j-davis.com> writes:
> Is this going in the right direction?
> And generally, is NLS translation of system messages wanted at all, or
> are ASCII messages more convenient anyway (given that it's just a
> simple text representation of errno)?
I do not like putting snprintf.c in charge of this, for certain.
That seems just plain nasty from a modularity/layering standpoint.
Also, the proposed implementation is not thread-safe, which is bad
right now on client-side regardless of whether it will be bad in
the future server-side.
> The status quo seems like an awkward middle ground, where the system
> messages are only translated on some platforms (perhaps only glibc?);
Well, they're translated if strerror() responds to LC_MESSAGES [1].
If it doesn't, then the users of that platform are unaccustomed to
seeing translated errno strings, and they are unlikely to thank us
for behaving differently from every other program on the platform.
So I don't really see any reason to think this proposal is an
improvement over what we have.
regards, tom lane
[1] Or at least that's the intent ... but I don't see translation
happening in HEAD on my Linux box:
regression=# create table zed(f1 text);
CREATE TABLE
regression=# copy zed from '/etc/shadow';
ERROR: could not open file "/etc/shadow" for reading: Permission denied
HINT: COPY FROM instructs the PostgreSQL server process to read a file. You may want a client-side facility such as
psql's\copy.
regression=# set lc_messages = 'es_ES';
SET
regression=# copy zed from '/etc/shadow';
ERROR: no se pudo abrir archivo <</etc/shadow>> para lectura: Permission denied
HINT: COPY FROM indica al proceso servidor de PostgreSQL leer un archivo. Puede desear usar una facilidad del lado del
clientecomo \copy de psql.
This surprises me, because pg_locale.c sets LC_MESSAGES "for real"
precisely so that strerror() will see it. We should look into
what is happening there.
