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: