Re: [INTERFACES] [pgaccess-users] RE: bugzilla.pgaccess.org
От | Bradley Baetz |
---|---|
Тема | Re: [INTERFACES] [pgaccess-users] RE: bugzilla.pgaccess.org |
Дата | |
Msg-id | Pine.LNX.4.44.0207110959490.10675-100000@tomato.home обсуждение исходный текст |
Ответ на | Re: [INTERFACES] [pgaccess-users] RE: (Rod Taylor <rbt@zort.ca>) |
Ответы |
Re: [INTERFACES] [pgaccess-users] RE:
|
Список | pgsql-hackers |
On 10 Jul 2002, Rod Taylor wrote: > On Wed, 2002-07-10 at 19:44, Bradley Baetz wrote: > > <delurk - reading from the archives, so please cc me on responses> > > > > Note that before bugzilla really supports postgresql, we (ie the bugzilla > > team) are going to need DROP COLUMN support, as well as support for > > changing a field's type. This is because thats how upgrades are done, when > > new features change the bz schema. > > Agreed it would be nice, but how come upgrades cannot be done with temp > tables -- especially since the bugzilla database is simple (no foreign > key constraints, etc.) If you're persisting with using ENUM(), a common > upgrade script won't work anyway. We don't plan on persisting in using enum :) <snip> > > You've just changed the datatype from a varchar to integer. With the > transaction support, you're guaranteed it won't be left mid way through > either. > Well, when bugzilla supports a db which supports foreign constraints, we'd like to add those in, too However, is there an easy way of obtaining the list of columns (and their types/indexes/etc) in a table, so that we can recreate table a with just that column missing? One which won't break when the underlying pg_* schema changes? The alternative is to pass the set of columns/indexes/etc into the DropColumn function each time its called, which would get messy quite quickly. Bradley
В списке pgsql-hackers по дате отправления: