> "Daniel Verite" writes:
>> 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
> I've used white space in the example, but I'm concerned about
> punctuation too.
>
> unicode.org has this helpful paper:
> http://www.unicode.org/L2/L2000/00260-sql.pdf
> which studies Unicode in SQL-99 identifiers.
>
> The relevant BNF they extracted from the standard looks like this:
>
>
2016-01-26 23:40 GMT-02:00 Tatsuo Ishii :
>> Thanks for advocate, I see here that it even produces that output with
>> simple spaces.
>>
>> postgres=# create table x ("aí " text);
>> CREATE TABLE
>> postgres=# \d x
>> Tabela "public.x"
>> Coluna | Tipo |
Tatsuo Ishii wrote:
> 2) What does the SQL standard say? Do they say that non ASCII white
> spaces should be treated as ASCII white spaces?
I've used white space in the example, but I'm concerned about
punctuation too.
unicode.org has this helpful paper:
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
"Daniel Verite" writes:
> 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
2016-01-27 6:24 GMT+01:00 Tatsuo Ishii :
> >> > 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
>> What do you exactly propose regarding white chars and multibyte chars
>> here? Maybe you propose to consider non ASCII white spaces (treate
>> them as ASCII white spaces)?
>>
>
> I propose the work with UTF white chars should be same like ASCII white
> chars. The current design is too simple -
> 2016-01-26 21:00 GMT+01:00 Daniel Verite :
>
>> 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"
>> > 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
2016-01-26 21:00 GMT+01:00 Daniel Verite :
> 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);
>
>
2016-01-27 6:13 GMT+01:00 Tatsuo Ishii :
> > 2016-01-26 21:00 GMT+01:00 Daniel Verite :
> >
> >> Tatsuo Ishii wrote:
> >>
> >> > IMO, it's a bug or at least an inconsistency
> >>
> >> Personally I don't see this change being good for
2016-01-27 8:25 GMT+01:00 Tatsuo Ishii :
> >> What do you exactly propose regarding white chars and multibyte chars
> >> here? Maybe you propose to consider non ASCII white spaces (treate
> >> them as ASCII white spaces)?
> >>
> >
> > I propose the work with UTF white chars
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,
2016-01-26 5:29 GMT-02:00 Tatsuo Ishii :
>
> I assume you used UTF-8 encoding database.
Yes, I do.
--
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://github.com/guedes - http://guedesoft.net
http://www.postgresql.org.br
--
Sent via
2016-01-26 18:00 GMT-02:00 Daniel Verite :
> ...
> 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
> Thanks for advocate, I see here that it even produces that output with
> simple spaces.
>
> postgres=# create table x ("aí " text);
> CREATE TABLE
> postgres=# \d x
> Tabela "public.x"
> Coluna | Tipo | Modificadores
> --+--+---
> aí | text |
>
>
>> 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,
> 2016-01-24 8:04 GMT-02:00 Tatsuo Ishii :
>>> On Wed, Jan 20, 2016 at 4:20 AM, Pavel Stehule
>>> wrote:
> If we would go this way, question is if we should back patch this or
> not since the patch apparently changes the existing
>
> On Wed, Jan 20, 2016 at 4:20 AM, Pavel Stehule
> wrote:
>>> If we would go this way, question is if we should back patch this or
>>> not since the patch apparently changes the existing
>>> behaviors. Comments? I would think we should not.
>>
>> I am sure, so we should
2016-01-24 8:04 GMT-02:00 Tatsuo Ishii :
>> On Wed, Jan 20, 2016 at 4:20 AM, Pavel Stehule
>> wrote:
If we would go this way, question is if we should back patch this or
not since the patch apparently changes the existing
behaviors.
On Wed, Jan 20, 2016 at 4:20 AM, Pavel Stehule wrote:
>> If we would go this way, question is if we should back patch this or
>> not since the patch apparently changes the existing
>> behaviors. Comments? I would think we should not.
>
> I am sure, so we should not
> Hi
>
> 2016-01-20 7:20 GMT+01:00 Tatsuo Ishii :
>
>> > 2016-01-20 3:47 GMT+01:00 Tatsuo Ishii :
>> >
>> >> test=# select format('%I', t) from t1;
>> >> format
>> >> --
>> >> aaa
>> >> "AAA"
>> >> "あいう"
>> >> (3 rows)
>> >>
>> >> Why is
2016-01-20 10:17 GMT+01:00 Tatsuo Ishii :
> > Hi
> >
> > 2016-01-20 7:20 GMT+01:00 Tatsuo Ishii :
> >
> >> > 2016-01-20 3:47 GMT+01:00 Tatsuo Ishii :
> >> >
> >> >> test=# select format('%I', t) from t1;
> >> >> format
> >> >>
test=# select format('%I', t) from t1;
format
--
aaa
"AAA"
"あいう"
(3 rows)
Why is the text value of the third line needed to be double quoted?
(note that it is a multi byte character). Same thing can be said to
quote_ident().
We treat identifiers made of the multi byte characters
2016-01-20 3:47 GMT+01:00 Tatsuo Ishii :
> test=# select format('%I', t) from t1;
> format
> --
> aaa
> "AAA"
> "あいう"
> (3 rows)
>
> Why is the text value of the third line needed to be double quoted?
> (note that it is a multi byte character). Same thing can be
> 2016-01-20 3:47 GMT+01:00 Tatsuo Ishii :
>
>> test=# select format('%I', t) from t1;
>> format
>> --
>> aaa
>> "AAA"
>> "あいう"
>> (3 rows)
>>
>> Why is the text value of the third line needed to be double quoted?
>> (note that it is a multi byte character).
Hi
2016-01-20 7:20 GMT+01:00 Tatsuo Ishii :
> > 2016-01-20 3:47 GMT+01:00 Tatsuo Ishii :
> >
> >> test=# select format('%I', t) from t1;
> >> format
> >> --
> >> aaa
> >> "AAA"
> >> "あいう"
> >> (3 rows)
> >>
> >> Why is the text value of
28 matches
Mail list logo