I guess the only viable option would be to the check explicitly ourselves. On Wed, Apr 27, 2016 at 11:25 AM, Will McCormick <wmccorm...@gmail.com> wrote:
> But this is the exact column definition that exists on the table when I > execute the statement .... > > It's like it does not check the pre-existing state of the column. Our code > is expecting a column already exists error but this error predicates that. > > On Wed, Apr 27, 2016 at 10:21 AM, Adrian Klaver <adrian.kla...@aklaver.com > > wrote: > >> On 04/27/2016 07:13 AM, Will McCormick wrote: >> >>> Why does this not work? From what I read only default values should >>> cause issue. I'm on release 9.4.4: >>> >>> >>> bms=# ALTER TABLE trap ALTER COLUMN trap_timestamp TYPE TIMESTAMP WITH >>> TIME ZONE; >>> ERROR: ALTER TABLE ... ALTER COLUMN TYPE may only affect UNLOGGED or >>> TEMPORARY >>> tables when BDR is active; trap is a regular table >>> >> >> http://bdr-project.org/docs/stable/ddl-replication-statements.html >> >> 8.2.3. DDL statements with restrictions >> >> ALTER TABLE >> >> Generally ALTER TABLE commands are allowed. There are a however >> several sub-commands that are not supported, mainly those that perform a >> full-table re-write. >> >> ... >> >> ALTER COLUMN ... TYPE - changing a column's type is not supported. >> Chaning a column in a way that doesn't require table rewrites may be >> suppported at some point. >> >> -- >> Adrian Klaver >> adrian.kla...@aklaver.com >> > >