Re: [HACKERS] problems with parser - Mailing list pgsql-hackers

Massimo Dal Zotto ha scritto:

> 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".

Yes but some times the parser understands the keyword varchar without "" as in:

create function "varchar"(float) returns varchar as                       ^^^^^^                      ^^^^^^
'begin       return $1;
end;
' language 'plpgsql';
CREATE

drop table a;
DROP
create table a (a float8);
CREATE
insert into a values (1.2);
INSERT 128074 1

or  in the CAST()...

select cast(a as varchar) from a;
varchar
-------   1.2
(1 row)

select varchar(a) from a;
ERROR:  parser: parse error at or near "a"
select "varchar"(a) from a;
varchar
-------   1.2
(1 row)



>
>         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@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  |
> +----------------------------------------------------------------------

PostgreSQL 6.5.0 on i586-pc-linux-gnu, compiled by gcc 2.7.2.3
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jose'