problems with parser

Поиск
Список
Период
Сортировка
От Massimo Dal Zotto
Тема problems with parser
Дата
Msg-id 199905031430.QAA03525@nikita.wizard.net
обсуждение исходный текст
Ответы Re: [HACKERS] problems with parser  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers
Hi,

I have some problems with the parser.

1)    Of the following queries, submitted with libpgtcl, the first two areparsed correctly while the third gives a
parseerror:
 
1.    select 12.    select 1; select 2;3.    select 1; select 2ERROR:  parser: parse error at or near ""
It seems that when a query consiste of two or more statements thelast one must be terminated by ';'. In my opinion this
isnotcorrect because it is not consistent with case 1) and because itbreaks many existing programs compatible with
previousversionsof pgsql where the syntax of point 2) was considered valid.
 
The same problem applies also to the body of sql functions, while itdoesn't apply to query submitted by psql because
theyare splittedin separate statements submitted one by one.
 

2)    The following query does't work:
create operator *= (         leftarg=_varchar,          rightarg=varchar,          procedure=array_varchareq);ERROR:
parser:parse error at or near "varchar"
 
The query should work because it is consistent with the documentedsyntax of the create operator:
Command: create operatorDescription: create a user-defined operatorSyntax:           CREATE OPERATOR operator_name (
      [LEFTARG = type1][,RIGHTARG = type2]           ,PROCEDURE = func_name,           [,COMMUTATOR = com_op][,NEGATOR
=neg_op]           [,RESTRICT = res_proc][,JOIN = join_proc][,HASHES]           [,SORT1 = left_sort_op][,SORT2 =
right_sort_op]);
and varchar is a valid type name (it is in pg_type).After a litte experimenting it turned out that varchar is also
areservedword and therefore not acceptable as a type name. To havethe above statement work you must quote the word
"varchar".
This is somewhat inconsistent with the syntax of create operatorand may confuse the user.

3)    The above query introduces another problem. How can the user knowwhat is wrong in the input. In the example
"parseerror at or near"is not a very explicative message. If I had read "reserved keyword"instead I would not have
spenttime trying to figure out what'swrong in my query.
 
The parser should be made more verbose and helpful about errors.

4)    And another related question: if the casual user can be confusedby obscure parser messages how can the postgres
hackerdebug theparser grammar? I tried with gdb but it is completely useless giventhe way the parser work.Is there any
toolor trick to debug the grammar?
 


-- 
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+


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

Предыдущее
От: Michael J Davis
Дата:
Сообщение: RE: [HACKERS] GROUP BY fixes committed
Следующее
От: Massimo Dal Zotto
Дата:
Сообщение: new patches for 6.5.0