Re: [HACKERS] problems with parser

From: José Soares <jose(at)sferacarta(dot)com>
To: Massimo Dal Zotto <dz(at)cs(dot)unitn(dot)it>
Cc: PostgreSQL Hackers <hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] problems with parser
Date: 1999-05-04 13:23:52
Message-ID: 372EF4E8.68901D68@sferacarta.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(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 |
> +----------------------------------------------------------------------

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-05-04 13:51:45 varchar-array.patch applied
Previous Message Thomas Lockhart 1999-05-04 13:17:49 [Fwd: Bug report.]