Re: LOCK for non-tables
От | Simon Riggs |
---|---|
Тема | Re: LOCK for non-tables |
Дата | |
Msg-id | 1295031876.23290.88.camel@ebony обсуждение исходный текст |
Ответ на | Re: LOCK for non-tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Fri, 2011-01-14 at 13:58 -0500, Tom Lane wrote: > 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. There's a similar issue on my new syntax for skipping the validation check on FKs. I'd appreciate it if you could propose a solution there also. I'm not sure whether I solved it, or am adding issues for the future. -- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: