Re: [HACKERS] Happy column dropping
| От | Don Baccus |
|---|---|
| Тема | Re: [HACKERS] Happy column dropping |
| Дата | |
| Msg-id | 3.0.1.32.20000123124518.01065400@mail.pacifier.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Happy column dropping (Bruce Momjian <pgman@candle.pha.pa.us>) |
| Ответы |
Re: [HACKERS] Happy column dropping
|
| Список | pgsql-hackers |
At 03:18 PM 1/23/00 -0500, Bruce Momjian wrote: >> That doesn't mean I have to like an "alter ... drop column" that doesn't >> really implement "alter ... drop column", though, does it? :) > >But is this really a bad thing. I think it is acceptible as is. We >currently tell people in the FAQ that do drop a column, do a SELECT INTO >... ALTER RENAME. That loses more than Peter's version. Again I'm missing not having Date here, I just called and it will be mailed to me next week. But I've been under the assumption that "alter table drop column" is part of SQL 92. If I'm wrong, then I suppose PostgreSQL can do whatever it wants. If it is part of SQL 92, though, shouldn't there at least be discussion of what's needed to actually implement the real, live standard semantics? Isn't the user who picks up PostgreSQL from, say, a Red Hat distribution going to be a bit surprised that "drop column" drops integrity constraints for the whole table? Assuming, of course, the feature as is were to go into release. >I can also say I would never have thought about the items Peter asked >about. I would have just implemented it as he did and maybe never even >considered the limitations. Hmmm...if it's part of SQL 92 I certainly would've looked at the defined semantics first. At least, that's what people pay me to do when I hack compilers... >We can't expect people to just walk up and produce portable, >style-conforming, totally functional code from day 1 or even year 1. >We work with people and point them in the right direction. And if I get organized to the point of being able to make contributions I would hope for tough, objective criticism of my efforts. >You know why ANALYZE is part of VACUUM? Because at the time I didn't >know how to scan a table. Vacuum already did that, so I piggybacked on >that code. This doesn't break standard semantics - again, if I'm wrong about alter table ... drop column being part of SQL 92 then I'll back off the suggestion that an implementation of standard semantics be explored. Maybe we should just drop this thread, I'm certainly not out to make any enemies. I've become fond of Postgres, and I guess my expectations and standards are just very high. Not that I'm always able to live up to them! :) - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
В списке pgsql-hackers по дате отправления: