problems with parser

From: Massimo Dal Zotto <dz(at)cs(dot)unitn(dot)it>
To: hackers(at)postgreSQL(dot)org (PostgreSQL Hackers)
Subject: problems with parser
Date: 1999-05-03 14:30:16
Message-ID: 199905031430.QAA03525@nikita.wizard.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

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?

--
Massimo Dal Zotto

+----------------------------------------------------------------------+
| Massimo Dal Zotto email: dz(at)cs(dot)unitn(dot)it |
| Via Marconi, 141 phone: ++39-0461534251 |
| 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ |
| Italy pgp: finger dz(at)tango(dot)cs(dot)unitn(dot)it |
+----------------------------------------------------------------------+

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 1999-05-03 14:51:29 Jsut a test of mail relaying ...
Previous Message Tom Lane 1999-05-03 14:29:50 Re: [HACKERS] an older problem? hash table out of memory