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