On Thu, Jun 2, 2011 at 10:47 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@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 <t...@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/VIEW interchangeably 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 available for 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
ALTER VIEW ALTER COLUMN SET/DROP DEFAULT
ALTER VIEW OWNER TO
ALTER VIEW SET SCHEMA
(There's no actual functionality gain 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 track of.
I did not disallow using ALTER TABLE for these operations. Perhaps we
should, but there's a backwards-compatibility issue if we do; in fact
it would break existing pg_dump scripts. I did however tighten up
ALTER SEQUENCE and ALTER VIEW to reject non-sequences and non-views
in the new cases as well as a couple of cases where they 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
