Re: [HACKERS] Well, then you keep your darn columns

> Let me thank all of those that spoke up in my support and let me tell of
> those that were unhappy that I _will_ be here tomorrow as well. To
> summarize the points and add a few of my own:
> 
> 1) This is a TODO item.
> 
> 2) I have reviewed several mutterings about how to implement this in the
> archives and followed the consensus that you need to copy the table over
> somehow. It's not like I made this up.

Yes, as Peter pointed out, he did exactly what I suggested in my e-mail
when he brought up the issue.  I don't even remember sending the
e-mail, so it must have been some time ago, 25 Nov 1999.

> 
> 2a) Does anyone have a better idea? (Btw., I'm not too excited about
> by-passing the storage manager and writing around in the table file on
> disk. If vacuum does that, that doesn't mean it's the right thing to do.)

I totally agree that bypassing the storage manager is the wrong way to
go with this.  All the command/*.c stuff is make to be clean, not fast. 
It is better to put something together that works rather than optimize
things like add user or create database.

Now, I will admit the ALTER DROP is going take much longer than most
command/*.c, so it may be worth it some day to try and do this, but I
don't see this as a priority at this point.  We have many other items to
work on that are more important.


> 6) Users have been begging for this but nobody else has moved a finger.

Totally true.

> 
> 7) If you are concerned about "perfect" implementation, then I invite you
> to take a look at the create/drop user and create/drop database code from
> 6.5 and thank whomever you do thank that your database isn't fried yet.

Yes, that stuff is a mess, and Peter has cleaned it up quite a bit.  And
I have already asked him about CLUSTER, which has serious problems.


> 8) Now that I know how to keep the oids around, they will be kept around.
> (Thanks to those that interpreted my message as a starting point for a
> discussion and not me laying down the law.)

Yes, it seems passing in the oid as part of heap_insert will do a good
job for us in a few other areas like when we want to modify the oid of a
tuple.  Withouth that, we if you delete a tuple, you can't add it back
in with the same oid.  That is pretty bad.

> 
> 9) What really gets me though is what your problem is. This is a nearly
> SQL-compliant implementation of a very important feature. It doesn't
> affect the rest of the code. It doesn't break the regression tests. It
> checks for permissions, validity of parameters, etc. and even if it goes
> wrong, it doesn't fry your database or any part of it.

Yes, I am still totally confused.  Let's hope it is just an aberation.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026