Re: ALTER TABLESPACE MOVE command tag tweak - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: ALTER TABLESPACE MOVE command tag tweak
Date
Msg-id 20140727134323.GC16422@tamriel.snowman.net
Whole thread Raw
In response to Re: ALTER TABLESPACE MOVE command tag tweak  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: ALTER TABLESPACE MOVE command tag tweak  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Alvaro,

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > > > Of course, we handle this in 'GRANT' with 'GRANT ON ALL TABLES', so why
> > > > not 'ALTER TABLE ON ALL TABLES IN TABLESPACE <blah>'?  that does get
> > > > pretty darn verbose but is at least a bit more in-line with what we have
> > > > done before..
> > >
> > > That's not a bad line of thought --- I doubt that verbosity is critical
> > > here.
> >
> > Alright, sounds like this is more-or-less the concensus.  I'll see about
> > making it happen shortly.
>
> Were you able to work on this?

Apologies, I've been gone more-or-less all of July.  I'm back now and
have time to spend on this.

> Can you be more specific on the exact grammar you're considering?  The
> proposal above,
> ALTER TABLE ON ALL TABLES IN TABLESPACE xyz
> doesn't seem very good to me.  I would think it'd be more like
> ALTER ALL TABLES IN TABLESPACE xyz
> but then if you return ALTER TABLE as a command tag that might be a bit
> strange.  Maybe
> ALTER TABLE ALL IN TABLESPACE xyz
> which AFAICS should work since ALL is already a reserved keyword.

Interesting idea.  I wonder if we might apply that to other capabilities
of ALTER TABLE too..  That is, make it a generic way to specify that all
tables in the tablespace (or schema..?) should be modified in a certain
way.  We'd have to consider which of the ALTER TABLE operations this
would work for, of course.  I don't believe it'd make sense for any of
the 'ADD/DROP COLUMN' or similar commands, but 'OWNER TO' would make
sense...

I'm not sure how much we want to work this over during beta though..  My
original thought was just to adjust the grammar and hopefully minimize
the other changes in this area, but it'd be good to have an idea about
where we want to take this, so the grammar can support the future
capabilities while not actually adding them at this time.

> Also, how would we document this?  Would we have it in the same page as
> all the ALTER TABLE variants, or would we create a separate page for
> ALTER TABLE ALL?  Keeping in mind that in the future we might want to
> allow things such as ALTER TABLE ALL IN SCHEMA xyz it might be better to
> have the selection logic documented neatly in its own little page
> instead of together with the ALTER TABLE mess which is already rather
> large.

I would think we'd simply use the ALTER TABLE page as I don't think the
documentation of this would be all that difficult to describe in a
reasonable paragraph.  A page dedicated to it feels like overkill, but
perhaps that might change as we add more.

Other thoughts on this?  We should really get any of the changes we're
doing here done soon.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: SKIP LOCKED DATA (work in progress)
Next
From: 李海龙
Date:
Subject: Re: 9.4 pg_control corruption