Peter Eisentraut <peter_e@gmx.net> writes:
> Thomas Lockhart writes:
>> Are dollar signs currently allowed in operators? I'd hate to reduce the
>> allowed number of characters for operators.
> They are, therefore identifiers couldn't start or end with a dollar in any
> case. However, single "$" operator cannot exist, so foo$bar wouldn't be
> ambiguous, but the tendency to confuse it with an operator syntax would
> reduce the readability of code greatly, IMO. However, a $$ operator can
> exist, so a construct like foo$$bar would parse completely differently,
> leaving you with a big mess.
Wups. Peter is more nearly correct than my previous message was.
I was misled by
regression=# select 1 $ 2;
ERROR: parser: parse error at or near "$"
But he's correct that "$" is part of the set of allowed operator
characters:
regression=# select 1 $$ 2;
ERROR: Unable to identify an operator '$$' for types 'integer' and 'integer' You will have to retype this query
usingan explicit cast
The reason a single $ does not work the same is that scan.l returns it
as itself (because it's in the "self" set), not as an Op. And gram.y
has no productions that involve '$' as a terminal symbol.
I am inclined to think that we should remove $ from the "self" list in
scan.l, which'd allow a single $ to be lexed as an Op. (This'd not
break parameters, since $n will still be preferentially lexed as a
"param", being longer than the token that could be formed using Op.)
In any case, this is sufficient reason why we cannot allow $ to be
allowed in identifiers: it will break any extant applications that use $
in user-defined operators.
regards, tom lane