> On May 20, 2020, at 11:24 AM, Tom Lane <tgl@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
charactersthat are allowed in postfix operators vs. those allowed for infix operators, then we'd get to have postfix
operatorswithout 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
todisallow 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
operatorsnamed 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
