Re: LOCK for non-tables
От | Tom Lane |
---|---|
Тема | Re: LOCK for non-tables |
Дата | |
Msg-id | 9253.1295031520@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: LOCK for non-tables (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: LOCK for non-tables
Re: LOCK for non-tables Re: LOCK for non-tables |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > Tom - I am willing to implement this if you think it's valuable, but > I'd like your input on the syntax. > http://archives.postgresql.org/pgsql-hackers/2011-01/msg00472.php It looks to me like the reason why there's a shift/reduce conflict is not so much that TABLE is optional as that we allow the syntax LOCK tablename NOWAIT If that weren't possible, then a table name would have to be followed by EOL or IN (which is full-reserved), while an optional object type name could not be followed by either, so there would be no shift/reduce conflict. So we broke it when we added NOWAIT, not when TABLE was made optional. So it looks to me like there are at least two fixes other than the ones you enumerated: 1. Make NOWAIT a reserved word. Not good, but perhaps better than reserving all the different object type names. 2. Disallow the above abbreviated syntax; allow NOWAIT only after an explicit IN ... MODE phrase. This would probably break a couple of applications, but I bet a lot fewer than changing the longer-established parts of the command syntax would break. I think #2 might be the best choice here. regards, tom lane
В списке pgsql-hackers по дате отправления: