> On May 20, 2020, at 11:24 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> Bottom line is that we can reduce the scope of the col-label problem
> this way, but we can't make it go away entirely. Is a partial solution
> to that worth a full drop of postfix operators? Possibly, but I'm not
> sure. I still feel like it'd be worth investigating some other solution
> technology, ie lookahead, though I concede your point that that has
> pitfalls too.
I should think a lot of the problem stems from allowing the same characters to
be used in postfix operators as in other operators. The ! character is already
not allowed as a column alias:
+SELECT 1 AS ! ORDER BY !;
+ERROR: syntax error at or near "!"
+LINE 1: SELECT 1 AS ! ORDER BY !;
+ ^
But you can use it as a prefix or infix operator, which creates the confusion
about whether
SELECT 5 ! x
Means "x" as an alias or as the right argument to the ! infix operator. But if
we made a clean distinction between the characters that are allowed in postfix
operators vs. those allowed for infix operators, then we'd get to have postfix
operators without the ambiguity, right?
When thinking about postfix operators, the subscript and superscript character
ranges come to my mind, such as
SELECT Σ₂(x² + y³ + z⁴);
These also come to mind as prefix operators, but I don't recall seeing them as
infix operators, so maybe it would be ok to disallow that? As for the ! infix
operator, it doesn't exist by default:
+SELECT x ! y from (select 5 AS x, 3 AS y) AS ss;
+ERROR: operator does not exist: integer ! integer
+LINE 1: SELECT x ! y from (select 5 AS x, 3 AS y) AS ss;
+ ^
+HINT: No operator matches the given name and argument types. You might need
to add explicit type casts.
So if we put that in the set of characters disallowed for infix operators, we
would only be breaking custom infix operators named that, which seems like less
breakage to me than removing postfix operators of all kinds.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
