Thread

1. Factorial operator gets parser error in psql.

   Robert B. Easter <reaster@comptechnews.com> — 2000-07-07T16:28:11Z

   SELECT 3 !;
   ERROR: parser error at or near ""
   
   SELECT 3 !
   ;
   Works ok.
   
   Parser error occurs if the ending ; is on the same line.
   
   -- 
   			Robert
   
   

2. Re: Factorial operator gets parser error in psql.

   Bruce Momjian <pgman@candle.pha.pa.us> — 2000-07-07T16:35:37Z

   Confirmed.  That is really weird.
   
   > 
   > SELECT 3 !;
   > ERROR: parser error at or near ""
   > 
   > SELECT 3 !
   > ;
   > Works ok.
   > 
   > Parser error occurs if the ending ; is on the same line.
   > 
   > -- 
   > 			Robert
   > 
   
   
   -- 
     Bruce Momjian                        |  http://candle.pha.pa.us
     pgman@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
   
   

3. Re: Factorial operator gets parser error in psql.

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-07-07T17:59:01Z

   "Robert B. Easter" <reaster@comptechnews.com> writes:
   > SELECT 3 !;
   > ERROR: parser error at or near ""
   
   > SELECT 3 !
   > ;
   > Works ok.
   
   > Parser error occurs if the ending ; is on the same line.
   
   Curious that
   	select 3 ! ;
   works differently from
   	select 3 !
   	;
   It appears that psql strips the ; from the query sent to the backend
   in the second case, but not in the first.
   
   The reason for the parse error is that the parser is deciding the ;
   must be a prefix "ln" operator and expecting to find a value after it.
   You get the same behavior, with possibly a little more intuitive
   reason for it, in
   	select 3 * ;
   
   This sort of bizarreness is why the ; and : operators are slated for
   destruction.  You can't overload ; as being both an operator and a
   statement terminator without running into ambiguities that will confuse
   both man and machine.  I suspect that the inconsistent behavior in psql
   is also rooted in the fact that psql can't be real sure what you mean
   the semicolon to be.
   
   BTW, with respect to your previous complaint: exp() is ambiguous because
   there are actually two exp() functions, one for float8 and one for
   numeric.  We need to teach the type resolver something about a
   reasonable promotion order for the numeric datatypes before it will be
   able to figure out by itself which one it should pick for an int4 input.
   (See long discussion in pg_hackers a few months ago.)  ": int4" is not
   ambiguous because pg_operator contains only one ":" operator, namely the
   float8 version of exp() ... but it would fail in just the same way if we
   had added an operator equivalent of exp(numeric).
   
   			regards, tom lane