Proposed patch to avoid translation risks in psql's \d commands

Started by Tom Laneover 18 years ago4 messagespatches
Jump to latest
#1Tom Lane
tgl@sss.pgh.pa.us

I proposed here:
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00436.php
that we change the way that psql deals with localization of column
names and other fixed strings in the output of \d and related commands
(basically, anything that calls printQuery()). Specifically, we should
avoid shipping already-translated strings to the server, because they
might not be in the expected encoding and also might contain quote
marks, which the existing code doesn't guard against. We can instead
apply the gettext() conversion when the query results come back from
the server.

The attached patch does this, and seems to resolve Guillaume Lelarge's
original complaint.

I found just one place where the proposed new method doesn't work quite
as nicely as the old. In \dC (describe casts), the Function column
contains either a function name or '(binary compatible)' to indicate
a cast WITHOUT FUNCTION. The existing code is able to localize '(binary
compatible)', but this patch does not, because applying gettext to every
value in the column seems to pose an unacceptably high risk of
"translating" some function name that happens to match a string in
psql's .PO database.

I'm inclined to just live with that, since it seems a relatively minor
deficiency, but I wonder if anyone has a better idea how to do it?

regards, tom lane

#2Guillaume Lelarge
guillaume@lelarge.info
In reply to: Tom Lane (#1)
Re: Proposed patch to avoid translation risks in psql's \d commands

Tom Lane a �crit :

I proposed here:
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00436.php
that we change the way that psql deals with localization of column
names and other fixed strings in the output of \d and related commands
(basically, anything that calls printQuery()). Specifically, we should
avoid shipping already-translated strings to the server, because they
might not be in the expected encoding and also might contain quote
marks, which the existing code doesn't guard against. We can instead
apply the gettext() conversion when the query results come back from
the server.

The attached patch does this, and seems to resolve Guillaume Lelarge's
original complaint.

It does resolve it. I applied your patch on my CVS HEAD checkout and it
works just great.

I found just one place where the proposed new method doesn't work quite
as nicely as the old. In \dC (describe casts), the Function column
contains either a function name or '(binary compatible)' to indicate
a cast WITHOUT FUNCTION. The existing code is able to localize '(binary
compatible)', but this patch does not, because applying gettext to every
value in the column seems to pose an unacceptably high risk of
"translating" some function name that happens to match a string in
psql's .PO database.

I'm inclined to just live with that, since it seems a relatively minor
deficiency, but I wonder if anyone has a better idea how to do it?

I have no problem with this. Other strings are not available for
translation (for example RECORD # when using the \x command) and that's
not really a big deal.

Thanks.

Regards.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Guillaume Lelarge (#2)
Re: Proposed patch to avoid translation risks in psql's \d commands

Guillaume Lelarge <guillaume@lelarge.info> writes:

Tom Lane a �crit :

The attached patch does this, and seems to resolve Guillaume Lelarge's
original complaint.

It does resolve it. I applied your patch on my CVS HEAD checkout and it
works just great.

Patch is applied to CVS.

regards, tom lane

#4Guillaume Lelarge
guillaume@lelarge.info
In reply to: Tom Lane (#3)
Re: Proposed patch to avoid translation risks in psql's \d commands

Tom Lane a �crit :

Guillaume Lelarge <guillaume@lelarge.info> writes:

Tom Lane a �crit :

The attached patch does this, and seems to resolve Guillaume Lelarge's
original complaint.

It does resolve it. I applied your patch on my CVS HEAD checkout and it
works just great.

Patch is applied to CVS.

Thanks.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com