Re: [INTERFACES] [pgaccess-users] RE: - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: [INTERFACES] [pgaccess-users] RE:
Date
Msg-id 1026348240.62546.69.camel@jester
Whole thread Raw
In response to Re: [INTERFACES] [pgaccess-users] RE: bugzilla.pgaccess.org  (Bradley Baetz <bbaetz@student.usyd.edu.au>)
Responses Re: [INTERFACES] [pgaccess-users] RE: bugzilla.pgaccess.org
List pgsql-hackers
> 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?

I see.  No, not that I know of.  You could take an SQL dump of the DB
and work on that, then restore at the end of the upgrade process -- but
thats not so good :)

Anyway, I'd *really* like to see PostgreSQL officially supported by
Bugzilla.

We may get DROP COLUMN in this release (Christopher?).

Changing data types probably won't appear. I don't know of anyone
working on it -- and it can be quite a complex issue to get a good
(resource friendly and transaction safe) version.

That said, if drop column is finished in time would the below be close
enough to do a data type change?:

alter table <table> rename <column> to <coltemp>;
alter table <table> add column <column> <newtype>;
update table <table> set <column> = <coltemp>;
alter table <table> drop column <coltemp>;


Are there any other requirements aside from drop column and altering
data types?





pgsql-hackers by date:

Previous
From: "Groff, Dana"
Date:
Subject: Re: Should this require CASCADE?
Next
From: Bradley Baetz
Date:
Subject: Re: [INTERFACES] [pgaccess-users] RE: bugzilla.pgaccess.org