Simon Riggs <si...@2ndquadrant.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
