Re: LOCK for non-tables

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Fri, 2011-01-14 at 16:09 -0500, Tom Lane wrote:
>> I think the realistic options are (1) change the syntax
>> non-backward-compatibly or (2) don't add any functionality here.

> (3) think of another way.

The only third way that I can see is to invent some new, unrelated
syntax for the new facilities. For example (just a straw man)

ACQUIRE LOCK FOR object-type object-name opt-lock-type opt-no-wait

The objection to this approach (which can also be lodged against your
function proposal) is that it's a larger burden on users: now they have
two syntaxes to remember, more complicated code to write if it needs to
use both syntaxes, etc. In the long run this is more trouble than a
one-time adjustment, especially if that adjustment can be limited to a
small number of uncommon cases.

> I'm not keen to explain to people how we broke their applications just
> because we wanted to add new functionality AND avoid one shift/reduce
> conflict in our SQL grammar. Avoiding changes to user code isn't third
> on that list of three things I want, its first.

I grow weary of discussions in which somebody argues that consideration
X always outweighs every other consideration. We're doing engineering
here, not theology, and there are always tradeoffs to be made. In this
case it's my opinion that a small syntax adjustment is the best
tradeoff.

regards, tom lane