Re: LOCK for non-tables

On Fri, Jan 07, 2011 at 08:16:33AM -0500, Robert Haas wrote:
> One of the things that I ripped out of the SQL/MED syntax patch before
> committing it was the hack that made LOCK TABLE also work on FOREIGN
> TABLEs. Since we're treating a foreign table as a different kind of
> object than a TABLE in some places, we shouldn't confuse the two
> things elsewhere, at least in my opinion. I also noticed that pg_dump
> has the following comment:
>
> * NOTE: it'd be kinda nice to lock other relations
> too, not only
> * plain tables, but the backend doesn't presently allow that.
>
> This is pretty trivial from a backend point of view, especially with
> the new objectaddress.c machinery. In a comparatively small amount of
> code we could support locks not only on all types of relations but
> also on any other backend objects we think it's worth supporting. The
> only difficulty is the grammar: we allow either "LOCK relname" or
> "LOCK TABLE relname", so adding e.g. "LOCK SEQUENCE relname" creates a
> shift/reduce conflict because SEQUENCE is unreserved. We can easily
> make "LOCK FOREIGN TABLE relname" work because FOREIGN is already
> full-reserved, but that seems to be the only case that can be done
> relatively painlessly.
>
> So, the options as I see them are:
>
> 1. Do nothing.
> 2. Support LOCK FOREIGN TABLE relname and forget about the rest.
> Feels fairly arbitrary, but avoids any hard decisions.
> 3. Partially reserve keywords like VIEW and SEQUENCE, and support LOCK
> [ TABLE | VIEW | SEQUENCE | FOREIGN TABLE ] relname. Doesn't really
> scale to other object types unless you keep reserving more keywords,
> but maybe we don't care.
> 4. Make the keyword TABLE required, and support LOCK { TABLE | VIEW |
> SEQUENCE | FOREIGN TABLE | maybe other object types } relname.

I'm not sure I understand this. Does it mean I'd have to say

LOCK TABLE my_view;

? If so, I don't think that's a great idea. We used to have to do
TABLE operations on SEQUENCEs because they just happened to be
implemented as special tables, which wired implementation details into
the API. This is Generally Not A Good Thing™, and we removed that
some time back.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate