Re: pgpool versus sequences - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pgpool versus sequences
Date
Msg-id BANLkTini-dHmzBxG0MN6g=z3qKbjxzQhCQ@mail.gmail.com
Whole thread Raw
In response to Re: pgpool versus sequences  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jun 2, 2011 at 10:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 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.
>
> [ shrug... ]  I don't find it so.  We have a convention that TABLE is
> an umbrella term for all applicable relation types.  End of story.
>
> Even if you disagree with that, the convention does exist, and making
> LOCK the one command type that disobeys it doesn't seem like a good
> plan.

I agree that wouldn't be a good plan to make LOCK inconsistent with
everything else, but LOCK is not the only case that's like this:

rhaas=# drop table v1;
ERROR:  "v1" is not a table
HINT:  Use DROP VIEW to remove a view.
rhaas=# comment on table v1 is 'v1 is a view';
ERROR:  "v1" is not a table
rhaas=# load 'dummy_seclabel';
LOAD
rhaas=# security label on table v1 is 'classified';
ERROR:  "v1" is not a table

As far as I can see, ALTER TABLE is just about the only place where we
allow this; and only for certain command types.  Your commit message
seems to indicate that we continue to allow that stuff only for
backward-compatibility:

commit a0b012a1ab85ae115f30e5e4fe09922b4885fdad
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Sun Jun 15 01:25:54 2008 +0000
   Rearrange ALTER TABLE syntax processing as per my recent proposal: the   grammar allows ALTER
TABLE/INDEX/SEQUENCE/VIEWinterchangeably for all   subforms of those commands, and then we sort out what's really legal
 at execution time.  This allows the ALTER SEQUENCE/VIEW reference pages   to fully document all the ALTER forms
availablefor sequences and views   respectively, and eliminates a longstanding cause of confusion for users. 
   The net effect is that the following forms are allowed that weren't before:       ALTER SEQUENCE OWNER TO
ALTERVIEW ALTER COLUMN SET/DROP DEFAULT       ALTER VIEW OWNER TO       ALTER VIEW SET SCHEMA   (There's no actual
functionalitygain here, but formerly you had to say   ALTER TABLE instead.) 
   Interestingly, the grammar tables actually get smaller, probably because   there are fewer special cases to keep
trackof. 
   I did not disallow using ALTER TABLE for these operations.  Perhaps we   should, but there's a
backwards-compatibilityissue if we do; in fact   it would break existing pg_dump scripts.  I did however tighten up
ALTERSEQUENCE and ALTER VIEW to reject non-sequences and non-views   in the new cases as well as a couple of cases
wherethey didn't before. 
   The patch doesn't change pg_dump to use the new syntaxes, either.

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


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: vacuum and row type
Next
From: Merlin Moncure
Date:
Subject: Re: PQdeleteTuple function in libpq