"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