Re: psql \dFp's behavior - Mailing list pgsql-hackers

From Tom Lane
Subject Re: psql \dFp's behavior
Date
Msg-id 6614.1197406781@sss.pgh.pa.us
Whole thread Raw
In response to Re: psql \dFp's behavior  (Guillaume Lelarge <guillaume@lelarge.info>)
Responses Re: psql \dFp's behavior
printQuery API change proposal (was Re: psql \dFp's behavior)
List pgsql-hackers
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.

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


pgsql-hackers by date:

Previous
From: Guillaume Lelarge
Date:
Subject: Re: psql \dFp's behavior
Next
From: "Dann Corbit"
Date:
Subject: Dumb question about binary cursors and #ifdef HAVE_INT64_TIMESTAMP