Thread: extended stats objects are the only thing written like "%s"."%s"
commit a4d75c86bf15220df22de0a92c819ecef9db3849 Author: Tomas Vondra <tomas.vondra@postgresql.org> Date: Fri Mar 26 23:22:01 2021 +0100 Extended statistics on expressions This commit added to psql/describe.c: + /* statistics object name (qualified with namespace) */ + appendPQExpBuffer(&buf, "\"%s\".\"%s\"", + PQgetvalue(result, i, 2), + PQgetvalue(result, i, 3)); Everywhere else the double quotes are around the whole "schema.object" rather than both separately: "schema"."object". The code handling servers before v14 has the same thing, since: commit bc085205c8a425fcaa54e27c6dcd83101130439b Author: Alvaro Herrera <alvherre@alvh.no-ip.org> Date: Fri May 12 14:59:23 2017 -0300 Change CREATE STATISTICS syntax src/bin/psql/describe.c- /* statistics object name (qualified with namespace) */ src/bin/psql/describe.c: appendPQExpBuffer(&buf, "\"%s\".\"%s\" (", src/bin/psql/describe.c- PQgetvalue(result, i, 2), src/bin/psql/describe.c- PQgetvalue(result, i, 3)); That seems to have been first added in the patch here, but AFAIT not specifically discussed. https://www.postgresql.org/message-id/20170511221330.5akgbsoyx6wm4u34%40alvherre.pgsql At the time the patch was commited, it was the only place that used "schema"."object": $ git show bc085205c8a425fcaa54e27c6dcd83101130439b:src/bin/psql/describe.c |grep '\\"\.\\"' appendPQExpBuffer(&buf, "\"%s\".\"%s\" (", And it's still the only place, not just in describe.c, but the entire project. $ git grep -Fc '\"%s\".\"%s\"' '*.c' src/bin/psql/describe.c:2 I actually don't like writing it as "a.b" since it doesn't work to copy+paste that, because that means an object called "a.b" in the default schema. But I think for consistency it should be done the same here as everywhere else. I noticed that Peter E recently changed amcheck in the direction of consistency: | 4279e5bc8c pg_amcheck: Message style and structuring improvements I propose to change extended stats objects to be shown the same as everywhere else, with double quotes around the whole %s.%s: $ git grep '\\"%s\.%s\\"' '*.c' |wc -l 126 This affects 9 lines of output in regression tests. Note that check constraints and indexes have the same schema as their table, so \d doesn't show a schema at all, and quotes the name of the object. That distinction may be relevant to how stats objects ended up being quoted like this. -- Justin
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > I think using "%s.%s" as is done everywhere else is pretty much > pointless. It's not usable as an object identifier, since you have to > make sure to remove the existing quotes, and unless the names work > without quotes, you have to add different quotes. So it looks «nice» > but it's functionally more work. 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. regards, tom lane
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.