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:  (Rod Taylor <rbt@zort.ca>)
Список 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 по дате отправления:

Предыдущее
От: Rod Taylor
Дата:
Сообщение: Re: [INTERFACES] [pgaccess-users] RE:
Следующее
От: "Groff, Dana"
Дата:
Сообщение: Re: Should this require CASCADE?