Re: full featured alter table?
От | Stephan Szabo |
---|---|
Тема | Re: full featured alter table? |
Дата | |
Msg-id | 20030612081334.Y26880-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: full featured alter table? (Sven Koehler <skoehler@upb.de>) |
Список | pgsql-general |
On Thu, 12 Jun 2003, Sven Koehler wrote: > > Pretty much when someone who cares about it enough comes along with > > a sufficient plan (and preferrably code) to implement it without breaking > > things would be my guess (especially given that AFAICS it's not part of > > either SQL92 or SQL99). Note that a sufficient plan would possibly > > involve a lot of things not directly involved with changing the type > > such as being able to deal with cached query plans for functions and > > such. > > In other word, nobody cares about that at the moment, and so this will > not be implemented. Actually, it's more that it's a big job (bigger than actually just changing the column) and it has some side issues about things like storage (can we use 2x space to do it, do we need to do something else, what happens if it fails part way due to something like a failure to convert data), stored plans (do plpgsql functions and foreign keys continue functioning after it, what about set returning functions that return that type), and probably other things that I can't think of. With limited resources, you have to make choices about what you work on. I'm sure Tom (for example) could have done it, but he possibly wouldn't have been able to do some or all of the error code stuff, protocol changes, expression indexes, various optimizer enhancements, bug fixes, etc. > something i hate most about opensource movement are these comments like > "submit a patch". your staments are not that rough, but i'd need more > time to get into the code than to implement the feature. > so if this feature was never foreseen, than it might get a heavy task, > and it might be even havier in a few years to implement that. It's actually probably going to move towards being easier over time hopefully, since some of the side issues are things that are probably going to be addressed anyway.
В списке pgsql-general по дате отправления: