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.
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.)
3) This isn't release software.
4) This isn't done. (But it will be.)
4a) If it won't get done then I add one line and it's disabled. I'm not
that dumb.
5) This isn't documented, so if you don't call the command then your life
goes on.
6) Users have been begging for this but nobody else has moved a finger.
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.
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.)
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.
Um, anyway, I'm open for implementation specific suggestions. I don't like
the coying either but it works.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
