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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026