Re: Allow an alias for the target table in UPDATE/DELETE

Andrew Dunstan <andrew@dunslane.net> writes:
> Presumably the effect in this case would be to prevent anyone from using
> SET as an alias unless there was a preceding AS.

I fooled around with this and found three feasible alternatives.

The simplest thing is:

relation_expr_opt_alias: relation_expr
            | relation_expr IDENT
            | relation_expr AS ColId

which at least gets us to the point of being able to use anything you
normally can use as an alias in other contexts, so long as you write AS.
Given the large and ever-increasing list of unreserved_keywords, though,
I don't think this is sufficient.

Then there's the precedence way.  This seems to work:

431a432
> %nonassoc    SET
5883c5884
< relation_expr_opt_alias: relation_expr
---
> relation_expr_opt_alias: relation_expr        %prec UMINUS
5887c5888,5895
<             | relation_expr opt_as IDENT
---
>             | relation_expr ColId
>                 {
>                     Alias *alias = makeNode(Alias);
>                     alias->aliasname = $2;
>                     $1->alias = alias;
>                     $$ = $1;
>                 }
>             | relation_expr AS ColId

The effect of this, as Andrew says, is that in this particular context
you can't write SET as an alias unless you write AS first.  This is
probably not going to surprise anyone in the UPDATE case, since the
ambiguity inherent in writing
    UPDATE foo set SET ...
is pretty obvious.  However it might surprise someone in the DELETE
context.  Another thing that worries me is that assigning a precedence
to the SET keyword might someday bite us by masking some other
grammatical ambiguity.  (As far as I can tell by comparing y.output
files, it's not changing the behavior of any other part of the grammar
today, but ...)

The third alternative is to stop allowing SET as an unreserved_keyword.
I found that moving it up to func_name_keyword was enough to get rid
of the conflict, without using precedence.  This is somewhat attractive
on the grounds of future-proofing (we may have to make SET more reserved
someday anyway for something else); and you can argue that the principle
of least astonishment demands that SET should be either always OK as an
alias or always not OK.  On the other hand this would raise some
backwards-compatibility issues.  Is it likely that anyone out there is
using SET as a table or column name?

I could live with either choice #2 or choice #3.  Comments?

            regards, tom lane