Re: BDR Alter table failing - Mailing list pgsql-general

From Will McCormick
Subject Re: BDR Alter table failing
Date
Msg-id CA+jgkY4=VRV+7jYNWWcMWGNB8dugNTmpO=kxUDcJ5o9b7PVG5Q@mail.gmail.com
Whole thread Raw
In response to Re: BDR Alter table failing  (Will McCormick <wmccormick@gmail.com>)
List pgsql-general
I guess the only viable option would be to the check explicitly ourselves.

On Wed, Apr 27, 2016 at 11:25 AM, Will McCormick <wmccormick@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.klaver@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.klaver@aklaver.com


pgsql-general by date:

Previous
From: Will McCormick
Date:
Subject: Re: BDR Alter table failing
Next
From: Alvaro Aguayo Garcia-Rada
Date:
Subject: Re: BDR Alter table failing