Re: Why format() adds double quote? - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: Why format() adds double quote?
Date
Msg-id cbd51d26-7716-4897-8698-a3cc91addc2f@mm
Whole thread Raw
In response to Re: Why format() adds double quote?  (Tatsuo Ishii <ishii@postgresql.org>)
Responses Re: Why format() adds double quote?
List pgsql-hackers
    Tatsuo Ishii wrote:

> What is the "visual hint"? If you are talking about psql's output, it
> never adds "visual hint" (double quotations).
>
> If you are talking about the string handling in a program, what kind
> of program cares about "visiual"?

Sure. The scenario I'm thinking about would be someone inspecting
generated queries, say for controlling or troubleshooting,
the queries containing identifiers injected with the help of
quote_ident/format. That could be from the logs, or
monitoring or audit tools.

If identifiers contain weird Unicode characters, currently
that's relatively easy to spot because they get surrounded by
double quotes.

If I see something like this: UPDATE "test․table" SET...
I immediately think that there's something fishy. It looks like test
should be a schema, but the surrounding quotes say otherwise.
In any case, it's clear that it updates a table in the current schema.

But if I see that: UPDATE test․table SET...
is seems legit and seems to update "table" inside the "test" schema
even though that's not what it does, it actually updates the
"test․table" table in the current schema, because the dot between
test and table is not the US-ASCII U+002E,  it's U+2024,
'ONE DOT LEADER'
On my display, they are almost indiscernible.

This boils down to the fact that the current quote_ident gives:

=# select quote_ident('test․table');quote_ident
--------------"test․table"

whereas the quote_ident patched as proposed gives:

=# select quote_ident('test․table');quote_ident
-------------test․table


So this is what I don't feel good about.

Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Existence check for suitable index in advance when concurrently refreshing.
Next
From: "Igal @ Lucee.org"
Date:
Subject: Implementing a new Scripting Language