Horton

Re: pgpool versus sequences

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Robert Haas <robertmhaas@gmail.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-02T15:10:00Z
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 →

  1. Rearrange ALTER TABLE syntax processing as per my recent proposal: the

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Tom Lane's message of jue jun 02 10:31:58 -0400 2011:
>> That's a lot of work for a purely cosmetic issue, though.  What would be
>> trivial is to let this work:
>> regression=# lock table s1;
>> ERROR:  "s1" is not a table

> Yeah, though it'd be nice to avoid this:

> alvherre=# create schema public_too;
> CREATE SCHEMA
> alvherre=# set search_path to 'public_too', 'public';
> SET
> alvherre=# create table public_too.s1 ();
> CREATE TABLE
> alvherre=# create sequence public.s1;
> CREATE SEQUENCE
> alvherre=# begin;
> BEGIN
> alvherre=# lock s1;
> LOCK TABLE

> At this point we have a lock on the table, but if we change LOCK to also
> look for sequences, the behavior would change.

No it wouldn't.  You seem to be imagining that sequences live in a
different namespace from tables, but they don't.  There can only be one
relation that "s1" will refer to for any search_path setting.

			regards, tom lane