Re: pgpool versus sequences
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Tatsuo Ishii <ishii@postgresql.org>, mangoo <mangoo@wpkg.org>, "scott.marlowe" <scott.marlowe@gmail.com>, "Kevin.Grittner" <kevin.grittner@wicourts.gov>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-06-02T14:42:37Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Rearrange ALTER TABLE syntax processing as per my recent proposal: the
- a0b012a1ab85 8.4.0 cited
On Thu, Jun 2, 2011 at 10:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Wed, Jun 1, 2011 at 7:47 PM, Alvaro Herrera >> <alvherre@commandprompt.com> wrote: >>> Yeah -- why is LOCK SEQUENCE foo_seq not allowed? Seems a simple thing >>> to have. > >> It cause a grammar conflict. > > That's a lot of work for a purely cosmetic issue, though. What would be > trivial is to let this work: > > regression=# create sequence s1; > CREATE SEQUENCE > regression=# begin; > BEGIN > regression=# lock table s1; > ERROR: "s1" is not a table > > We should do that anyway, even if we put in the effort to support the > other syntax. Ugh. We are already stuck supporting all kinds of backward compatibility cruft in tablecmds.c as a result of the fact that you used to have to use ALTER TABLE to operate on views and sequences. The whole thing is confusing and a mess. -1 from me on extending that mess to more places. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company