Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison |
Date | |
Msg-id | 199910051813.OAA22735@candle.pha.pa.us Whole thread Raw |
List | pgsql-hackers |
> > hmmm that's strange. I tested this also this morning with a pretty > > simple program. I will attach the program to this email and place > > the output here. It's a quiet simple program. Just create a table, fill > > it and do select * from test1 -- comment ...and see what it does. > > This is the output: > > > > DBD::Pg::st execute failed: ERROR: parser: > > parse error at or near "-" > > DBD::Pg::st fetchrow_array failed: no statement > > executing > > can't execute -- comment: ERROR: parser: parse > > error at or near "-" > > > > this is why I thought it was done in the front end and not in the > > backend. Is there a way to solve this. PS the comment with /* */ is > > going okay this way. > > I just connected to the backend and did it directly, and it worked: > > postgres -D /u/pg/data test > > POSTGRES backend interactive interface > $Revision: 1.130 $ $Date: 1999/09/29 16:06:10 $ > > backend> select * from test1 -- comment > blank > 1: x (typeid = 23, len = 4, typmod = -1, byval = t) > ---- > backend> > > So, there must be something in the perl interface that is causing the > problem. I don't have pgperl defined here, so I am not sure, but I can > record it as a bug. > > Now, if I do this: > > backend> -- testssdf > ERROR: parser: parse error at or near "" > ERROR: parser: parse error at or near "" > > it shouldn't throw an error, but it does. psql doesn't mind it, though. > Strange. Same with /* lkjas;ldfjk */. Seems we have a bug there > because non-psql interfaces can send these queries. OK, I am applying the following patch to fix the above problem. The old code, which I wrote, took care of trailing semicolons, but did not really fix the problems of comment-only lines, and lines containing many semicolons next to each other. This code is much cleaner, and regression tests seem to like it. I know this problem was reported before, and Thomas had made some comment about needing it fixed. This will be applied to 6.6 only. Seems to dangerous for 6.5.*. [Not sure if the perl test is going to be OK after this fix. Looks like something inside perl may be the problem. Maybe there is some code in the perl interface to strip out -- comments? ] -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 echo: cannot create /dev/ttyp5: permission denied Index: gram.y =================================================================== RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/gram.y,v retrieving revision 2.106 diff -c -r2.106 gram.y *** gram.y 1999/10/03 23:55:30 2.106 --- gram.y 1999/10/05 18:01:41 *************** *** 365,384 **** %left UNION INTERSECT EXCEPT %% ! stmtblock: stmtmulti opt_semi { parsetree = $1; } ; stmtmulti: stmtmulti ';' stmt ! { $$ = lappend($1, $3); } | stmt ! { $$ = lcons($1,NIL); } ; - opt_semi: ';' - | /*EMPTY*/ - ; - stmt : AddAttrStmt | AlterUserStmt | ClosePortalStmt --- 365,393 ---- %left UNION INTERSECT EXCEPT %% ! /* ! * Handle comment-only lines, and ;; SELECT * FROM pg_class ;;; ! * psql already handles such cases, but other interfaces don't. ! * bjm 1999/10/05 ! */ ! stmtblock: stmtmulti { parsetree = $1; } ; stmtmulti: stmtmulti ';' stmt ! { if ($3 != (Node *)NIL) ! $$ = lappend($1, $3); ! else ! $$ = $1; ! } | stmt ! { if ($1 != (Node *)NIL) ! $$ = lcons($1,NIL); ! else ! $$ = (Node *)NIL; ! } ; stmt : AddAttrStmt | AlterUserStmt | ClosePortalStmt *************** *** 423,428 **** --- 432,439 ---- | VariableShowStmt | VariableResetStmt | ConstraintsSetStmt + | /*EMPTY*/ + { $$ = (Node *)NIL; } ; /*****************************************************************************
pgsql-hackers by date: