Re: extended stats objects are the only thing written like "%s"."%s"
От | Peter Eisentraut |
---|---|
Тема | Re: extended stats objects are the only thing written like "%s"."%s" |
Дата | |
Msg-id | 1d99357f-53c4-0568-3dcf-2d17c3717b22@enterprisedb.com обсуждение исходный текст |
Ответ на | extended stats objects are the only thing written like "%s"."%s" (Justin Pryzby <pryzby@telsasoft.com>) |
Список | pgsql-hackers |
On 30.08.21 20:06, Alvaro Herrera wrote: > On 2021-Aug-28, Tom Lane wrote: > >> I think what we are doing there is following the message style >> guideline that says to put double quotes around inserted strings. >> In this case schema.object (as a whole) is the inserted string. >> People often confuse this with SQL double-quoted identifiers, but it >> has nothing whatsoever to do with SQL's rules. (It's easier to make >> sense of this rule in translations where the quote marks are not >> ASCII double-quotes ... like your example with «nice».) >> >> In short: Justin is right, this should not be done this way. > > I don't agree with the way we're applying the message guidelines here, > but since this is the only place where we do this, I've changed it to > the idiomatic way of quoting names. I agree that the current situation is not satisfactory. We should think about extending the guidelines to cover this. Note that it's not necessarily enough to say, leave \"%s\".\"%s\" untranslated. For example, this could create inconsistencies with analogous messages that don't include a schema qualification. Also, unless we are being careful about escaping double-quoted strings inside the substituted strings, it wouldn't be entirely correct either. A comprehensive approach across the tree would be preferable, perhaps with additional APIs to support it. Also, the question when schema qualifications should be printed or not should be answered.
В списке pgsql-hackers по дате отправления: