Re: [HACKERS] problems with parser

[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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026