Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id 878C8B6094C
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Thu,  2 Jun 2011 11:28:35 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024)
	with ESMTP id 79319-01; Thu,  2 Jun 2011 14:28:28 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pz0-f46.google.com (mail-pz0-f46.google.com
	[209.85.210.46])
	by mail.postgresql.org (Postfix) with ESMTP id 8FE55B606CD;
	Thu,  2 Jun 2011 11:28:27 -0300 (ADT)
Received: by pzk9 with SMTP id 9so411225pzk.19
	for <multiple recipients>; Thu, 02 Jun 2011 07:28:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=i2xsurwjpzMb1QRpau9sh2ojfO4DfxQJ+nek0AeGRyQ=;
	b=gfSwQdLylH1XQkOj0FBUz+Sem9h5Ly0ebMz104Louk2uHT+u18/8MOMumCfulIRGAb
	DX6r4BdzEHOJ++IH6PhxuV/WTA+24+xKCbRyd3kfMNwQ6gSB+utwSIYnff69hu6lDiv4
	LZuG7+uyMzAFNvu3GwxRnLNFIVevzbU6MAHCM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	b=abfvOHFEuYKbi3RoO17uGRJuYh26k0EoDQu1h7fE9BAjuLjaDnPhi4h/9iWyrTaucp
	TRSiAhDlNXXuc4dsVPK766DOeyluz5fq+sam6ySHMwcHuZZ/9LT82vKDfN/APPDrf5Xf
	cdJxKAvbQ4vhtt8+VF8sunMdnMjqTqs3B4wQY=
MIME-Version: 1.0
Received: by 10.68.31.234 with SMTP id d10mr287198pbi.490.1307024907426; Thu,
	02 Jun 2011 07:28:27 -0700 (PDT)
Received: by 10.68.56.70 with HTTP; Thu, 2 Jun 2011 07:28:27 -0700 (PDT)
In-Reply-To: <1306971997-sup-5549@alvh.no-ip.org>
References: <26909.1306965898@sss.pgh.pa.us>
	<BANLkTikCRTeZ_g-rDay4RukWOY3Q7irCnQ@mail.gmail.com>
	<27741.1306968830@sss.pgh.pa.us>
	<20110602.080816.460114267356667394.t-ishii@sraoss.co.jp>
	<1306971997-sup-5549@alvh.no-ip.org>
Date: Thu, 2 Jun 2011 10:28:27 -0400
Message-ID: <BANLkTimgVA7mi2SP_ZVH-fsUB3VShTsMng@mail.gmail.com>
Subject: Re: pgpool versus sequences
From: Robert Haas <robertmhaas@gmail.com>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Tatsuo Ishii <ishii@postgresql.org>, tgl <tgl@sss.pgh.pa.us>,
	mangoo <mangoo@wpkg.org>, "scott.marlowe" <scott.marlowe@gmail.com>,
	"Kevin.Grittner" <kevin.grittner@wicourts.gov>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.898 tagged_above=-5 required=5 tests=BAYES_00=-1.9,
	FREEMAIL_FROM=0.001, RFC_ABUSE_POST=0.001
X-Spam-Level: 
X-Archive-Number: 201106/120
X-Sequence-Number: 188833

On Wed, Jun 1, 2011 at 7:47 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Tatsuo Ishii's message of mi=E9 jun 01 19:08:16 -0400 2011:
>> What pgpool really wanted to do was locking sequence tables, not
>> locking rows in sequences. I wonder why the former is not allowed.
>
> Yeah -- why is LOCK SEQUENCE foo_seq not allowed? =A0Seems a simple thing
> to have.

It cause a grammar conflict.  Since SEQUENCE and NOWAIT are both
unreserved keywords, it's not clear to the parser whether "LOCK
SEQUENCE NOWAIT" means to lock a table called SEQUENCE without
waiting, or whether it means to lock a sequence called NOWAIT.

Tom and I discussed possible ways of fixing this on -hackers a few
months ago.  Currently the syntax for LOCK is:

LOCK [ TABLE ] [ ONLY ] name [, ...] [ IN lockmode MODE ] [ NOWAIT ];

I suggested fixing this by making TABLE required, thus:

LOCK TABLE [ ONLY ] name [, ...] [ IN lockmode MODE ] [ NOWAIT ];

Tom suggested fixing it by making NOWAIT require IN lockmode MODE, thus:

LOCK [ TABLE ] [ ONLY ] name [,...] [ IN lockmode MODE [ NOWAIT ]];

My proposed fix is probably more likely to break people's
applications, but Tom's isn't completely free from that possibility
either.  It's also somewhat counterintuitive IMV.  The best option
might be to come up with some completely new syntax that is a little
better designed than the current one, maybe along the lines of the
extensible-options syntax used by EXPLAIN.  The trouble is that the
first word of the command would probably have to be something other
than LOCK if we don't want to break backward compatibility with the
existing syntax in some way, and there aren't too many good synonyms
for LOCK.  LATCH? FASTEN? Blech.  We're probably going to end up
having to make a compatibility break here if we want to support this.

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company