Re: [HACKERS] problems with parser - Mailing list 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