Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Thanks. One more tweak --- the whole reason for fiddling with this is
> to ensure that event triggers support this operation. Therefore this
> node should be handled by ProcessUtilitySlow, not
> standard_ProcessUtility, as in the attac
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > ALTER TABLE ALL IN TABLESPACE xyz
> > > which AFAICS should work since ALL is already a reserved keyword.
> >
> > Pushed to master and REL9_4_STABLE.
>
>
Stephen Frost wrote:
> Alvaro,
>
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > ALTER TABLE ALL IN TABLESPACE xyz
> > which AFAICS should work since ALL is already a reserved keyword.
>
> Pushed to master and REL9_4_STABLE.
Thanks. One more tweak --- the whole reason for fiddling with
Fujii,
* Fujii Masao (masao.fu...@gmail.com) wrote:
> On Fri, Aug 22, 2014 at 8:14 AM, Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >> ALTER TABLE ALL IN TABLESPACE xyz
> >> which AFAICS should work since ALL is already a reserved keyword.
> >
> > Pushed to master
Fujii,
* Fujii Masao (masao.fu...@gmail.com) wrote:
> You seem to have forgotten to update tab-complete.c.
Good point, absolutely correct. I have a bad tendency to do that.
> Attached patch updates that.
Many thanks, will review and apply soon.
Thanks again!
Stephen
On Fri, Aug 22, 2014 at 8:14 AM, Stephen Frost wrote:
> Alvaro,
>
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>> ALTER TABLE ALL IN TABLESPACE xyz
>> which AFAICS should work since ALL is already a reserved keyword.
>
> Pushed to master and REL9_4_STABLE.
You seem to have forgotten to up
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> ALTER TABLE ALL IN TABLESPACE xyz
> which AFAICS should work since ALL is already a reserved keyword.
Pushed to master and REL9_4_STABLE. Apologies on it taking so long-
things have a bit "interesting" for me over the past month or two
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 8/17/14 5:19 PM, Stephen Frost wrote:
> > Alvaro, all,
> >
> > * Stephen Frost (sfr...@snowman.net) wrote:
> >> As mentioned, I'll add this to the ALTER TABLE documentation and remove
> >> it from the TABLESPACE docs. That's not done yet but I shou
On 8/17/14 5:19 PM, Stephen Frost wrote:
> Alvaro, all,
>
> * Stephen Frost (sfr...@snowman.net) wrote:
>> As mentioned, I'll add this to the ALTER TABLE documentation and remove
>> it from the TABLESPACE docs. That's not done yet but I should have time
>> in the next few days to get that done al
On 15 Aug 2014 19:06, "Robert Haas" wrote:
>
> > As for the expanded-mode changes, I thought there was consensus to
> > revert that from 9.4.
>
> Me too. In fact, I think that's been the consensus for many months,
> but unless I'm mistaken it ain't done.
Yeah, this is entirely my fault. I was tr
Alvaro, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> As mentioned, I'll add this to the ALTER TABLE documentation and remove
> it from the TABLESPACE docs. That's not done yet but I should have time
> in the next few days to get that done also and will then commit it all
> to master and bac
Alvaro, all,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> 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
On Fri, Aug 15, 2014 at 9:57 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Aug 14, 2014 at 6:12 PM, Tom Lane wrote:
>>> If it weren't for the fact that we'll be wedded forevermore to a bad
>>> choice of syntax, I might agree with you. But at this point, the
>>> alternatives we have are t
Robert Haas writes:
> On Thu, Aug 14, 2014 at 6:12 PM, Tom Lane wrote:
>> If it weren't for the fact that we'll be wedded forevermore to a bad
>> choice of syntax, I might agree with you. But at this point, the
>> alternatives we have are to fix it now, or fix it never. I don't
>> like #2.
> O
On Thu, Aug 14, 2014 at 6:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> We really should not be making changes of this type less than a month
>> from our ostensible release date. That is not enough time for us to
>> notice if the changes turn out to be not as good as we think they are.
>
> If
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > We really should not be making changes of this type less than a month
> > from our ostensible release date. That is not enough time for us to
> > notice if the changes turn out to be not as good as we think they are.
>
> If it were
Robert Haas writes:
> We really should not be making changes of this type less than a month
> from our ostensible release date. That is not enough time for us to
> notice if the changes turn out to be not as good as we think they are.
If it weren't for the fact that we'll be wedded forevermore t
On Wed, Aug 13, 2014 at 9:33 AM, Alvaro Herrera
wrote:
> Stephen Frost wrote:
>
>> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>> > Stephen Frost wrote:
>
>> > > Alright, sounds like this is more-or-less the concensus. I'll see about
>> > > making it happen shortly.
>> >
>> > Were you able
Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Stephen Frost wrote:
> > > 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
Alvaro,
* Alvaro Herrera (alvhe...@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 '? that does get
> > > > pretty darn verbose but is at least a bit more in-line wi
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > That it's more-or-less a bulk 'ALTER TABLE' operation is why I had been
> > > trying to think of a way to put it under that command. What if we had a
> > > more general way to reference 'all objects in a
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > That it's more-or-less a bulk 'ALTER TABLE' operation is why I had been
> > trying to think of a way to put it under that command. What if we had a
> > more general way to reference 'all objects in a tablespace'?
> > "tablespace.*
Noah Misch wrote:
> Concerning the problem that started this thread, I would raise one ALTER TABLE
> event per table and not fire an event for the bulk request as a whole.
Yes, that's how it already works. Essentially, ALTER TABLESPACE MOVE
calls AlterTableInternal, and that function calls one A
On Mon, Jun 23, 2014 at 05:10:02PM -0400, Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > I'm not against changing it- doing operations on a whole tablespace felt
> > like it would make sense under 'ALTER TABLESPACE' to me (hence th
Tom Lane wrote:
> Stephen Frost writes:
> > That it's more-or-less a bulk 'ALTER TABLE' operation is why I had been
> > trying to think of a way to put it under that command. What if we had a
> > more general way to reference 'all objects in a tablespace'?
> > "tablespace.*" or "ALL:TABLESAPCE"?
Stephen Frost writes:
> That it's more-or-less a bulk 'ALTER TABLE' operation is why I had been
> trying to think of a way to put it under that command. What if we had a
> more general way to reference 'all objects in a tablespace'?
> "tablespace.*" or "ALL:TABLESAPCE"? Are there other places wh
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
>
> > Any further thoughts on this? I haven't tried to go implement anything
> > yet but I'm definitely concerned that we may run into a keyword issue
> > with ALTER TABLE, but I don't really want to add 'TABLES' either.
>
Stephen Frost wrote:
> Any further thoughts on this? I haven't tried to go implement anything
> yet but I'm definitely concerned that we may run into a keyword issue
> with ALTER TABLE, but I don't really want to add 'TABLES' either.
> Anyone have any other suggestions or ideas?
I thought that t
All,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Alvaro Herrera writes:
> > > ALTER TABLESPACE MOVE is a glorified ALTER TABLE. If ALTER TABLESPACE
> > > MOVE returned ALTER TABLE as a tag, I think it'd work well too; but not
> > > ALTER TABLESPACE.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera writes:
> > ALTER TABLESPACE MOVE is a glorified ALTER TABLE. If ALTER TABLESPACE
> > MOVE returned ALTER TABLE as a tag, I think it'd work well too; but not
> > ALTER TABLESPACE. Individually, since the implementation works by
> > calling
Alvaro Herrera writes:
> The problem in this particular case is that TABLESPACE is a "global"
> object, thus not supported; but ALTER TABLESPACE MOVE is a command that
> modifies tables (which *are* supported), not tablespaces.
> ALTER TABLESPACE MOVE is a glorified ALTER TABLE. If ALTER TABLESP
Tom Lane wrote:
> Alvaro Herrera writes:
> > The ALTER TABLESPACE MOVE command affects tables, not tablespaces; and
> > as such, I think event triggers should support that command. I'm not
> > proposing to change event triggers at this stage, but since IMO we will
> > want to do that in 9.5, we n
Alvaro Herrera writes:
> The ALTER TABLESPACE MOVE command affects tables, not tablespaces; and
> as such, I think event triggers should support that command. I'm not
> proposing to change event triggers at this stage, but since IMO we will
> want to do that in 9.5, we need it to have a different
The ALTER TABLESPACE MOVE command affects tables, not tablespaces; and
as such, I think event triggers should support that command. I'm not
proposing to change event triggers at this stage, but since IMO we will
want to do that in 9.5, we need it to have a different command tag than
plain ALTER TA
34 matches
Mail list logo
