From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, "Dickson S(dot) Guedes" <listas(at)guedesoft(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why format() adds double quote? |
Date: | 2016-01-27 04:56:24 |
Message-ID: | CAFj8pRA-oLconoJ5V0ZPTrHyWAyw2bEvusXArgdrvnzxGz=vcw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2016-01-26 21:00 GMT+01:00 Daniel Verite <daniel(at)manitou-mail(dot)org>:
> Tatsuo Ishii wrote:
>
> > IMO, it's a bug or at least an inconsistency
>
> Personally I don't see this change being good for everything.
>
> Let's play devil's advocate:
>
> create table abc(U&"foo\2003" int);
>
> U+2003 is 'EM SPACE', in Unicode's General Punctuation block.
>
> With the current version, format('%I', attname) on this column is:
> "foo "
>
> With the patched version, it produces this:
> foo
>
> So the visual hint that there are more characters at the end is lost.
>
I can agree, so current behave can be useful in some cases, but still it is
bug (inconsistency) between PostgreSQL parser and PostgreSQL escaping
functions.
Currently, any multibyte char can be unescaped identifier (only apostrophes
are tested). We should to test white chars too.
Regards
Pavel
>
> Best regards,
> --
> Daniel Vérité
> PostgreSQL-powered mailer: http://www.manitou-mail.org
> Twitter: @DanielVerite
>
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2016-01-27 05:11:07 | Code of Conduct plan |
Previous Message | Amit Kapila | 2016-01-27 04:39:50 | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |