Re: psql \dFp's behavior

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: psql \dFp's behavior
Дата
Msg-id 6614.1197406781@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: psql \dFp's behavior  (Guillaume Lelarge <guillaume@lelarge.info>)
Ответы Re: psql \dFp's behavior  (Guillaume Lelarge <guillaume@lelarge.info>)
printQuery API change proposal (was Re: psql \dFp's behavior)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Guillaume Lelarge
Дата:
Сообщение: Re: psql \dFp's behavior
Следующее
От: "Dann Corbit"
Дата:
Сообщение: Dumb question about binary cursors and #ifdef HAVE_INT64_TIMESTAMP