Re: psql \dFp's behavior

Tom Lane a écrit :
> 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 "Début 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.
>

Which is why I choose to look at the code and write a patch.

> 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.
>

Oh, that's true. I didn't think about that but I understand your concerns.

> 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'll take a look at this.

Thanks for your answer.

Regards.

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