A general re-organization of Alter Table. Node wise, it is a
AlterTableStmt with a list of AlterTableCmds. The Cmds are the
individual actions to be completed (Add constraint, drop constraint, add
column, etc.)
Processing is done in 2 phases. The first phase updates the system
catalogs and create
Is this to be applied to CVS HEAD?
---
Rod Taylor wrote:
> A general re-organization of Alter Table. Node wise, it is a
> AlterTableStmt with a list of AlterTableCmds. The Cmds are the
> individual actions to be completed (
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this to be applied to CVS HEAD?
It sounded like large portions were still at the request-for-comment
stage...
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze i
On Tue, 2003-11-11 at 23:46, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is this to be applied to CVS HEAD?
>
> It sounded like large portions were still at the request-for-comment
> stage...
It can be applied to -HEAD without breaking anything or backtracking in
feature set (
Rod Taylor writes:
> ALTER TABLE tab ADD COLUMN col DEFAULT 3, ADD CHECK (anothercol > 3);
> The above combinational syntax is commented out in gram.y. The
> support framework is used in both the above and below items, but
> arbitrary statements probably have some issues --
On Wed, 2003-11-12 at 14:02, Peter Eisentraut wrote:
> Rod Taylor writes:
>
> > ALTER TABLE tab ADD COLUMN col DEFAULT 3, ADD CHECK (anothercol > 3);
> I think it's perfectly fine to write two separate ALTER TABLE statements.
> No need to introduce this nonstandard syntax.
Yes, it is certainly f
Peter Eisentraut kirjutas K, 12.11.2003 kell 21:02:
> Rod Taylor writes:
>
> > ALTER TABLE tab ADD COLUMN col DEFAULT 3, ADD CHECK (anothercol > 3);
> > The above combinational syntax is commented out in gram.y. The
> > support framework is used in both the above and below items, b
Rod Taylor writes:
> Yes, it is certainly fine to do so, but much faster to do the above.
Are table schema changes performance-sensitive operations, and are they
usually done in bulk? I doubt it.
> I've not found another database which allows this syntax. The suggestion
> of TRANSFORM was Toms
Hannu Krosing writes:
> > Please don't use the term "transform". It is used by the SQL standard for
> > other purposes.
>
> Is the "other" use conflicting with this syntax ?
>
> I think we have preferred reusing existing keywords to adding new ones
> in the past.
Maybe (although I don't agree).
On Thu, 2003-11-13 at 09:18, Peter Eisentraut wrote:
> Rod Taylor writes:
>
> > Yes, it is certainly fine to do so, but much faster to do the above.
>
> Are table schema changes performance-sensitive operations, and are they
> usually done in bulk? I doubt it.
Perhaps not for you. But I would d
Rod Taylor kirjutas N, 13.11.2003 kell 16:59:
>
> Can you please suggest a better term to use in place of TRANSFORM?
> Perhaps UPDATE WITH?
or perhaps USING, based loosely on our use of USING in CREATE INDEX ?
--
Hannu
---(end of broadcast)
Rod,
I tried the current patch on a RC2 release, and I noticed one
undesirable side affect.
Modifying a column moves it to the end. In high availability situations
this would not be desirable, I would imagine it would break lots of
code.
Dave
On Thu, 2003-11-13 at 11:35, Hannu Krosing wrote:
>
On Fri, Nov 14, 2003 at 08:59:05AM -0500, Dave Cramer wrote:
> I tried the current patch on a RC2 release, and I noticed one
> undesirable side affect.
>
> Modifying a column moves it to the end. In high availability situations
> this would not be desirable, I would imagine it would break lots
Alvaro Herrera kirjutas R, 14.11.2003 kell 16:17:
> On Fri, Nov 14, 2003 at 08:59:05AM -0500, Dave Cramer wrote:
>
> > I tried the current patch on a RC2 release, and I noticed one
> > undesirable side affect.
> >
> > Modifying a column moves it to the end. In high availability situations
> > t
On Fri, 2003-11-14 at 08:59, Dave Cramer wrote:
> Rod,
>
> I tried the current patch on a RC2 release, and I noticed one
> undesirable side affect.
>
> Modifying a column moves it to the end. In high availability situations
> this would not be desirable, I would imagine it would break lots of
>
Rod Taylor writes:
> The method is rename old column, add new column, move data across, move
> or reform dependencies, drop old column.
I can do this by hand. If we have an explicit command to do it, then it
needs to preserve the table schema. Else, this feature would be mostly
useless and a ce
On Fri, 2003-11-14 at 09:57, Peter Eisentraut wrote:
> Rod Taylor writes:
>
> > The method is rename old column, add new column, move data across, move
> > or reform dependencies, drop old column.
>
> I can do this by hand. If we have an explicit command to do it, then it
> needs to preserve the
OK,
Here is another approach, that would retain column order. It will
require that the table be locked while this proceeds, but I think this
is a good idea anyway.
lock table
create newtable as select c1, c2, c3::newtype
modify pg_class to point to the new filename
modify existing pg_attribute fo
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Fri, 2003-11-14 at 09:57, Peter Eisentraut wrote:
>> I can do this by hand. If we have an explicit command to do it, then it
>> needs to preserve the table schema. Else, this feature would be mostly
>> useless and a certain source of complaints.
> The
> lock table
> create newtable as select c1, c2, c3::newtype
> modify pg_class to point to the new filename
> modify existing pg_attribute for the column in question
> recreate indexes that exist on the column
> unlock table
I actually tried this to start with an ran into several dead-ends in
tryi
Tom Lane writes:
> I believe the consensus was that automating what you could do by hand
> is still a step forward.
I don't recall that, but if so, I would like to revisit that consensus.
AFAICT, this patch does not buy us anything at all. It's just a different
spelling of existing functionalit
Peter Eisentraut kirjutas R, 14.11.2003 kell 18:51:
> Tom Lane writes:
>
> > I believe the consensus was that automating what you could do by hand
> > is still a step forward.
>
> I don't recall that, but if so, I would like to revisit that consensus.
>
> AFAICT, this patch does not buy us anyth
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Peter Eisentraut kirjutas R, 14.11.2003 kell 18:51:
>> I don't recall that, but if so, I would like to revisit that consensus.
> [ Hannu disagrees ]
Please take this thread to pgsql-hackers; if the issue is going to be
contentious then we should try to
This is expected. Doing otherwise would incur into a much bigger
performance hit.
Anyway, IMHO no code should use SELECT * in any case, which is the only
scenario where one would expect physical column order to matter, isn't
it?
Well, we can always bring back the old idea of a attlognum which is t
I guess the real question here is whether we would want to revert this
capability if a patch to adjust logical column orderings doesn't appear
before 7.5. My vote would be "no", but apparently Peter's is "yes".
Any other opinions?
The fact that it deals with the nightmare of dropping and recreati
Rod Taylor kirjutas L, 08.11.2003 kell 18:55:
> A general re-organization of Alter Table. Node wise, it is a
> AlterTableStmt with a list of AlterTableCmds. The Cmds are the
> individual actions to be completed (Add constraint, drop constraint, add
> column, etc.)
>
> Processing is done in 2 phas
26 matches
Mail list logo
