Re: psql \dFp's behavior

Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:
> Tom Lane a crit :
>> This seems mighty ugly, and it's not the way we handle any other \d
>> command. Why is it needed for \dFp (and only that)?

> The problem here is that "Start parse" is translated with "Dbut de
> l'analyse" (which is a bad translation but that's not the point).

Well, that particular issue could be fixed if the translated string
doubled the quote mark. Which I agree is a pretty fragile solution.

describe.c's whole approach to this has always been pretty thoroughly
broken in my mind, because it makes untenable assumptions about the
client-side gettext() producing strings that are in the current
client_encoding. If they are not, the server will probably reject
the SQL query as failing encoding verification.

We should be fixing it so that the translated strings never go to the
server and back at all. This doesn't seem amazingly hard for column
headings --- it'd take some API additions in print.c, I think.
If we are actually embedding translated words in the data
then it'd be a bigger problem.

> I found \dFp but we could have the same problems with \dp

IIRC, *all* the \d commands do this.

regards, tom lane