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