Re: Allow an alias for the target table in UPDATE/DELETE
От | Tom Lane |
---|---|
Тема | Re: Allow an alias for the target table in UPDATE/DELETE |
Дата | |
Msg-id | 18627.1137954383@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Allow an alias for the target table in UPDATE/DELETE (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Allow an alias for the target table in UPDATE/DELETE
(Andrew Dunstan <andrew@dunslane.net>)
Re: Allow an alias for the target table in UPDATE/DELETE (Neil Conway <neilc@samurai.com>) |
Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления:
Предыдущее
От: Andrew DunstanДата:
Сообщение: Re: Allow an alias for the target table in UPDATE/DELETE