Обсуждение: BUG #7899: allow key word as alias in subquery but Can't reference it in outer query

Поиск
Список
Период
Сортировка

BUG #7899: allow key word as alias in subquery but Can't reference it in outer query

От
"Jov"
Дата:
The following bug has been logged on the website:

Bug reference:      7899
Logged by:          jov
Email address:      amutu@amutu.com
PostgreSQL version: 9.1.3
Operating system:   CentOS 6
Description:        

xxx=# select 2 from (select 1 as end) t;   
 ?column? 
----------
        2
(1 row)

xxx=# select end from (select 1 as end) t;
ERROR:  syntax error at or near "end"
LINE 1: select end from (select 1 as end) t;
               ^

xxx=# select version();  
                                                   version                  
                               
  
------------------------------------------------------------------------------------------------------------
--
 PostgreSQL 9.1.3 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.5
20110214 (Red Hat 4.4.5-6), 64-bi
t
(1 row)

I think use key word as alias should get a error message such as $key_word
is Key Word,should not be used as identifier bla bla,so for some complex
query error user can save a lot of time. 

Re: BUG #7899: allow key word as alias in subquery but Can't reference it in outer query

От
Tom Lane
Дата:
"Jov" <amutu@amutu.com> writes:
> xxx=# select end from (select 1 as end) t;
> ERROR:  syntax error at or near "end"
> LINE 1: select end from (select 1 as end) t;
>                ^

You need to double-quote the outer use of "end", viz

regression=# select "end" from (select 1 as end) t;end
-----  1
(1 row)

In the context with "as", Postgres can tell the word is meant as a
column identifier not a keyword, but there's no way for it to know that
in the outer usage.

> I think use key word as alias should get a error message such as $key_word
> is Key Word,should not be used as identifier bla bla,so for some complex
> query error user can save a lot of time.

Well, yours is the first complaint we've ever had in that direction,
whereas we used to get a lot of complaints in the opposite direction,
back when we didn't allow keywords to be used for column names.
So I doubt we'll change it.  It is an interesting gotcha though :-(
        regards, tom lane



Re: BUG #7899: allow key word as alias in subquery but Can't reference it in outer query

От
Jov
Дата:
I have get the description of this behaviour from doc 7.3.2
http://www.postgresql.org/docs/devel/static/queries-select-lists.html#QUERI=
ES-COLUMN-LABELS
.

from the error message now,I think syntax error may emmit by the
parser,parser error make it hard to get the really condition such as the
second token =91end=92 is a select item from a select statement.

thanks

2013/2/22 Tom Lane <tgl@sss.pgh.pa.us>

> "=3D?ISO-8859-1?B?Sm92?=3D" <amutu@amutu.com> writes:
> > xxx=3D# select end from (select 1 as end) t;
> > ERROR:  syntax error at or near "end"
> > LINE 1: select end from (select 1 as end) t;
> >                ^
>
> You need to double-quote the outer use of "end", viz
>
> regression=3D# select "end" from (select 1 as end) t;
>  end
> -----
>    1
> (1 row)
>
> In the context with "as", Postgres can tell the word is meant as a
> column identifier not a keyword, but there's no way for it to know that
> in the outer usage.
>
> > I think use key word as alias should get a error message such as
> $key_word
> > is Key Word,should not be used as identifier bla bla,so for some comple=
x
> > query error user can save a lot of time.
>
> Well, yours is the first complaint we've ever had in that direction,
> whereas we used to get a lot of complaints in the opposite direction,
> back when we didn't allow keywords to be used for column names.
> So I doubt we'll change it.  It is an interesting gotcha though :-(
>
>                         regards, tom lane
> .
>
>


--=20
Jov
blog: http:amutu.com/blog <http://amutu.com/blog>

Re: BUG #7899: allow key word as alias in subquery but Can't reference it in outer query

От
Jov
Дата:
can we make a cross reference from doc 4.4.1(
http://www.postgresql.org/docs/devel/static/sql-syntax-lexical.html#SQL-SYN=
TAX-IDENTIFIERS
)
to
doc 7.3.2 (
http://www.postgresql.org/docs/devel/static/queries-select-lists.html#QUERI=
ES-COLUMN-LABELS
)
*to mention that =93AS=94 can make a key word to be a identifier?*
I have read the doc 4.4.1 and can't find this info from there so I thin it
is a bug.

2013/2/22 Jov <amutu@amutu.com>

> I have get the description of this behaviour from doc 7.3.2
>
> http://www.postgresql.org/docs/devel/static/queries-select-lists.html#QUE=
RIES-COLUMN-LABELS
> .
>
> from the error message now,I think syntax error may emmit by the
> parser,parser error make it hard to get the really condition such as the
> second token =91end=92 is a select item from a select statement.
>
> thanks
>
> 2013/2/22 Tom Lane <tgl@sss.pgh.pa.us>
>
>> "=3D?ISO-8859-1?B?Sm92?=3D" <amutu@amutu.com> writes:
>> > xxx=3D# select end from (select 1 as end) t;
>> > ERROR:  syntax error at or near "end"
>> > LINE 1: select end from (select 1 as end) t;
>> >                ^
>>
>> You need to double-quote the outer use of "end", viz
>>
>> regression=3D# select "end" from (select 1 as end) t;
>>  end
>> -----
>>    1
>> (1 row)
>>
>> In the context with "as", Postgres can tell the word is meant as a
>> column identifier not a keyword, but there's no way for it to know that
>> in the outer usage.
>>
>> > I think use key word as alias should get a error message such as
>> $key_word
>> > is Key Word,should not be used as identifier bla bla,so for some compl=
ex
>> > query error user can save a lot of time.
>>
>> Well, yours is the first complaint we've ever had in that direction,
>> whereas we used to get a lot of complaints in the opposite direction,
>> back when we didn't allow keywords to be used for column names.
>> So I doubt we'll change it.  It is an interesting gotcha though :-(
>>
>>                         regards, tom lane
>> .
>>
>>
>
>
> --
> Jov
> blog: http:amutu.com/blog <http://amutu.com/blog>
>



--=20
Jov
blog: http:amutu.com/blog <http://amutu.com/blog>