> 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
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
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.
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
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
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.
23 matches
Mail list logo
