Re: Why format() adds double quote?

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "Tatsuo Ishii" <ishii(at)postgresql(dot)org>
Cc: listas(at)guedesoft(dot)net,robertmhaas(at)gmail(dot)com,pavel(dot)stehule(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why format() adds double quote?
Date: 2016-01-27 16:07:52
Message-ID: cbd51d26-7716-4897-8698-a3cc91addc2f@mm
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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,
On my display, they are almost indiscernible.

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

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

whereas the quote_ident patched as proposed gives:

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

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

Best regards,
Daniel Vérité
PostgreSQL-powered mailer:
Twitter: @DanielVerite

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Igal @ 2016-01-27 16:27:36 Implementing a new Scripting Language
Previous Message Masahiko Sawada 2016-01-27 16:01:24 Re: Existence check for suitable index in advance when concurrently refreshing.