Zeugswetter Andreas SB wrote:
> > This style of "DROP COLUMN" would change the attribute
> > numbers whose positons are after the dropped column.
> > Unfortunately we have no mechanism to invalidate/remove
> > objects(or prepared plans) which uses such attribute numbers.
> > And I've seen no pro
> Both options are in Oracle now, as proudly documented in their
> freely accessible on-line documentation. It is very possible
> they didn't implement it until version 8, i.e. until a couple of years
> ago.
FYI: ALTER TABLE DROP COLUMN was added as of 8 / 8i according to our
Oracle DBA.
- mer
On Mon, Oct 16, 2000 at 06:51:10PM +1100, Chris wrote:
> KuroiNeko wrote:
>
> > 1 create table alpha( id int4, payload text );
>
>
> > Not a big deal, right?
>
> Yes a big deal. You just lost all your oids.
Been there. Done that. Learned to heed the warnings about using
oids in any
> > Not a big deal, right?
>
> Yes a big deal. You just lost all your oids.
After I hit the wall with oids for the first time, I don't refer to them
anymore :) But yes, you're perfectly right, this is one more reason to have
DDL completely `automated,' ie no manual substitutions.
And here th
> I think we do, because it solves more than just the ALTER DROP COLUMN
> problem: it cleans up other sore spots too. Like ALTER TABLE ADD COLUMN
> in a table with child tables.
Yes, could also implement "add column xx int before someothercolumn"
to add a column in the middle.
Andreas
At 10:56 PM 10/15/00 +0900, Hiroshi Inoue wrote:
>When I used Oracle,I saw neither option of DROP COLUMN
>feature. It seems to tell us that the implementation isn't
>that easy. It may not be a bad choise to give up DROP
>COLUMN feature forever.
Both options are in Oracle now, as proudly documen
> This style of "DROP COLUMN" would change the attribute
> numbers whose positons are after the dropped column.
> Unfortunately we have no mechanism to invalidate/remove
> objects(or prepared plans) which uses such attribute numbers.
> And I've seen no proposal/discussion to solve this problem
>
Chris wrote:
>
> Hiroshi Inoue wrote:
>
> > When I used Oracle,I saw neither option of DROP
> > COLUMN feature. It seems to tell us that the
> > implementation isn't
> > that easy. It may not be a bad choise to give up DROP
> > COLUMN feature forever.
>
> Because it's not easy we shouldn't do i
Hiroshi Inoue wrote:
> We could easily break the consistency of DB due to
> careless implementations.
I'm sure no-one around here would do careless implementations. :-)
Chris wrote:
> Hiroshi Inoue wrote:
>
> > When I used Oracle,I saw neither option of DROP
> > COLUMN feature. It seems to tell us that the
> > implementation isn't
> > that easy. It may not be a bad choise to give up DROP
> > COLUMN feature forever.
>
> Because it's not easy we shouldn't do it?
Hiroshi Inoue wrote:
> Certainly it would need 2x.
> However is ADD COLUMN DEFAULT really needed ?
> I would do as follows.
>
> ADD COLUMN (without default)
> UPDATE .. SET new_column = new default
> ALTER TABLE ALTER COLUMN SET DEFAULT
Well in current postgres that would use 2x. Wi
Chris wrote:
> Hiroshi Inoue wrote:
>
> > When I used Oracle,I saw neither option of DROP
> > COLUMN feature. It seems to tell us that the
> > implementation isn't
> > that easy. It may not be a bad choise to give up DROP
> > COLUMN feature forever.
>
> Because it's not easy we shouldn't do it?
Hiroshi Inoue wrote:
> When I used Oracle,I saw neither option of DROP
> COLUMN feature. It seems to tell us that the
> implementation isn't
> that easy. It may not be a bad choise to give up DROP
> COLUMN feature forever.
Because it's not easy we shouldn't do it? I don't think so. The perfect
KuroiNeko wrote:
> 1 create table alpha( id int4, payload text );
> Not a big deal, right?
Yes a big deal. You just lost all your oids.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> This said, I think Hiroshi's patch seems a perfect starting point, no ?
>
> > Having phantom columns adds additional complexity to the system overall.
> > We have to decide we really want it before making things more complex
> > th
KuroiNeko wrote:
> Inoue san,
>
> > This style of "DROP COLUMN" would change the attribute
> > numbers whose positons are after the dropped column.
> > Unfortunately we have no mechanism to invalidate/remove
> > objects(or prepared plans) which uses such attribute numbers.
>
> 1 create table al
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > My trial implementation using physical/logical attribute numbers
> > isn't so clean as I expected. I'm inclined to restrict my change to
> > fix the TODO
> > * ALTER TABLE A
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> My trial implementation using physical/logical attribute numbers
> isn't so clean as I expected. I'm inclined to restrict my change to
> fix the TODO
> * ALTER TABLE ADD COLUMN to inherited table put column in wrong place
> though it would also introdu
Inoue san,
> This style of "DROP COLUMN" would change the attribute
> numbers whose positons are after the dropped column.
> Unfortunately we have no mechanism to invalidate/remove
> objects(or prepared plans) which uses such attribute numbers.
1 create table alpha( id int4, payload text );
2
> My trial implementation using physical/logical attribute numbers
> isn't so clean as I expected. I'm inclined to restrict my change to
> fix the TODO
> * ALTER TABLE ADD COLUMN to inherited table put column in wrong place
> though it would also introduce a backward compatibility.
> I could live
> -Original Message-
> From: Don Baccus [mailto:[EMAIL PROTECTED]]
>
> At 04:23 PM 10/12/00 +0200, Zeugswetter Andreas SB wrote:
>
> >My conclusion would be that we need both:
> >1. a fast system table only solution with physical/logical column id
> >2. a tool that does the cleanup (e.g.
At 04:23 PM 10/12/00 +0200, Zeugswetter Andreas SB wrote:
>My conclusion would be that we need both:
>1. a fast system table only solution with physical/logical column id
>2. a tool that does the cleanup (e.g. vacuum)
Oracle provides both styles of "drop column" - the "hide the column's
data an
On Fri, 13 Oct 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > okay, but, again based on my impression of what Tom has stated, and
> > previous conversations on this topic, the key problem is what happens if I
> > drop a column and a later date decide add a new column of
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> okay, but, again based on my impression of what Tom has stated, and
> previous conversations on this topic, the key problem is what happens if I
> drop a column and a later date decide add a new column of the same name,
> what happens?
I'm not very
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> This said, I think Hiroshi's patch seems a perfect starting point, no ?
> Having phantom columns adds additional complexity to the system overall.
> We have to decide we really want it before making things more complex
> than they already are.
I think
On Fri, 13 Oct 2000, Zeugswetter Andreas SB wrote:
>
> > Hiroshi's patch would make for a good starting point by bringing in the
> > ability to do the DROP COLUMN feature, as I understand, without the
> > rollback capability,
>
> No Hiroshi's patch is rollback enabled, simply because all it doe
Tom Lane wrote:
>
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> > My conclusion would be that we need both:
> > 1. a fast system table only solution with physical/logical column id
> > 2. a tool that does the cleanup (e.g. vacuum)
>
> But the peak space usage during cleanup must still b
> Hiroshi's patch would make for a good starting point by bringing in the
> ability to do the DROP COLUMN feature, as I understand, without the
> rollback capability,
No Hiroshi's patch is rollback enabled, simply because all it does is change
some system tables. It only does not free space tha
On Fri, 13 Oct 2000, Bruce Momjian wrote:
> [ Charset ISO-8859-1 unsupported, converting... ]
> > > we bite the bullet to the extent of supporting a distinction between
> > > physical and logical column numbers, then ISTM there's no strong need
> > > to do any of this other stuff at all. I'd exp
[ Charset ISO-8859-1 unsupported, converting... ]
> > we bite the bullet to the extent of supporting a distinction between
> > physical and logical column numbers, then ISTM there's no strong need
> > to do any of this other stuff at all. I'd expect that an inserted or
> > updated tuple would hav
> we bite the bullet to the extent of supporting a distinction between
> physical and logical column numbers, then ISTM there's no strong need
> to do any of this other stuff at all. I'd expect that an inserted or
> updated tuple would have a NULL in any physical column position that
> doesn't ha
> > My conclusion would be that we need both:
> > 1. a fast system table only solution with physical/logical column id
> > 2. a tool that does the cleanup (e.g. vacuum)
>
> But the peak space usage during cleanup must still be 2X.
The difference for a cleanup would be, that it does not need to
On Thu, 12 Oct 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > On Thu, 12 Oct 2000, Tom Lane wrote:
> >> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> My conclusion would be that we need both:
> 1. a fast system table only solution with physical/logical
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> On Thu, 12 Oct 2000, Tom Lane wrote:
>> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
My conclusion would be that we need both:
1. a fast system table only solution with physical/logical column id
2. a tool that does the cleanup (
On Thu, 12 Oct 2000, Tom Lane wrote:
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> > My conclusion would be that we need both:
> > 1. a fast system table only solution with physical/logical column id
> > 2. a tool that does the cleanup (e.g. vacuum)
>
> But the peak space usage during
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> My conclusion would be that we need both:
> 1. a fast system table only solution with physical/logical column id
> 2. a tool that does the cleanup (e.g. vacuum)
But the peak space usage during cleanup must still be 2X.
> WAL would provide the framework to do something like that, but I still
> say it'd be a bad idea. What you're describing is
> irrevocable-once-it-starts DROP COLUMN; there is no way to
> roll it back.
> We're trying to get rid of statements that act that way, not add more.
Yes.
> I am not con
> > being deleted, then if the system crashes part way through,
> it should be
> > possible to continue after the system is brought up, no?
>
> If it crashes in the middle, some rows have the column
> removed, and some
> do not.
We would need to know where this separation is, but we cannot do
38 matches
Mail list logo
