problems with parser - Mailing list pgsql-hackers

From Massimo Dal Zotto
Subject problems with parser
Date
Msg-id 199905031430.QAA03525@nikita.wizard.net
Whole thread Raw
Responses Re: [HACKERS] problems with parser
List 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 by date:

Previous
From: Michael J Davis
Date:
Subject: RE: [HACKERS] GROUP BY fixes committed
Next
From: Massimo Dal Zotto
Date:
Subject: new patches for 6.5.0