Re: Factorial operator gets parser error in psql.
От | Tom Lane |
---|---|
Тема | Re: Factorial operator gets parser error in psql. |
Дата | |
Msg-id | 11033.962992741@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Factorial operator gets parser error in psql. ("Robert B. Easter" <reaster@comptechnews.com>) |
Список | pgsql-bugs |
"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
В списке pgsql-bugs по дате отправления: