Re: [HACKERS] problems with parser
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] problems with parser |
Дата | |
Msg-id | 199905101706.NAA08250@candle.pha.pa.us обсуждение исходный текст |
Ответ на | problems with parser (Massimo Dal Zotto <dz@cs.unitn.it>) |
Список | pgsql-hackers |
[Charset ISO-8859-1 unsupported, filtering to ASCII...] > Hi, > > I have some problems with the parser. > > 1) Of the following queries, submitted with libpgtcl, the first two are > parsed correctly while the third gives a parse error: > > 1. select 1 > 2. select 1; select 2; > 3. select 1; select 2 > ERROR: parser: parse error at or near "" > > It seems that when a query consiste of two or more statements the > last one must be terminated by ';'. In my opinion this is not > correct because it is not consistent with case 1) and because it > breaks many existing programs compatible with previous versions > of pgsql where the syntax of point 2) was considered valid. > > The same problem applies also to the body of sql functions, while it > doesn't apply to query submitted by psql because they are splitted > in separate statements submitted one by one. Added to TODO list. > > 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 documented > syntax of the create operator: > > Command: create operator > Description: create a user-defined operator > Syntax: > 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 a > reserved word and therefore not acceptable as a type name. To have > the above statement work you must quote the word "varchar". > > This is somewhat inconsistent with the syntax of create operator > and may confuse the user. Also added to TODO list. > > 3) The above query introduces another problem. How can the user know > what is wrong in the input. In the example "parse error at or near" > is not a very explicative message. If I had read "reserved keyword" > instead I would not have spent time trying to figure out what's > wrong 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 confused > by obscure parser messages how can the postgres hacker debug the > parser grammar? I tried with gdb but it is completely useless given > the way the parser work. > Is there any tool or trick to debug the grammar? I have not looked at this particular problem, but usually the errror generated by the parser are poor. Unfortunately, I don't know of any way to insert our own error messaged based on the type of parser failure. This is locked up in yacc/bison. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления:
Следующее
От: jwieck@debis.com (Jan Wieck)Дата:
Сообщение: Re: [HACKERS] Some info about subselect/having problems