"unexpected" query behaviour after i change parser code

Поиск
Список
Период
Сортировка
От Mohammad Heykal Abdillah
Тема "unexpected" query behaviour after i change parser code
Дата
Msg-id 1274534467.2964.110.camel@claudia
обсуждение исходный текст
Ответы Re: "unexpected" query behaviour after i change parser code  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
All,

Lately i have play with "parser"-part. I was try to make valid query
command without using "FROM clause", so far it's work.

I know this modification will make all query that using "FROM clause"
failed, for example "/df" command. But normal or simple "select
statement" so far is work.

Now before my question, this what i do to make query without FROM clause
work :
1) change "src/backend/parser/gram.y" at "simple_select:" delete
from_clause
2) change "src/backend/parser/parse_relation.c" at function
warnAutoRange, comment or delete "if (!add_missing_from)" part and
change the "else" above to "if (add_missing_from)".

Ok this my test result to "customer" and "item" table :
- select id_item,name from item;
--> failed, because there is "from clause" (failed like i expected)

- select item.id_item, item.name;
--> work, like i expected

- select id_item,name;
--> failed, with error : column "id_item" does not exist (failed like i
expected)

- select item.id_item,customer.fname;
--> work, the data not acurate though because there is no joined atribut

- select item.id_item,customer.fname where item.id_item=customer.id;
--> work, normaly

- select item.id,item;
--> work, the result was concanted in "item" column. (i expected this
query was failed). Try many combination including using more than one
table with previous test, the result always work ONLY IF i put
"table_name.colId" first.

My question :
1) Can someone explain why my last test it's work?

2) Why PostgreSQL won't query my 3rd test?
Considering my last test it's work.

Thank You.

*) Btw if you try my modification make sure you already have the data. I
havent try any command yet, but i assume SET, or CREATE will failed.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexey Klyukin
Дата:
Сообщение: Re: Specification for Trusted PLs?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Idea for getting rid of VACUUM FREEZE on cold pages