Re: psql \dFp's behavior

Tom Lane a écrit :
> Guillaume Lelarge <guillaume@lelarge.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.orghttp://dalibo.com