Re: BDR Alter table failing

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Will McCormick <wmccormick(at)gmail(dot)com>
Cc: Alvaro Aguayo Garcia-Rada <aaguayo(at)opensysperu(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: BDR Alter table failing
Date: 2016-04-28 05:11:21
Message-ID: CAMsr+YHKLExz36CVK9nd9uxWDFTPeDU3Cs=xkg-5FJ907=u-Aw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 28 April 2016 at 02:47, Will McCormick <wmccormick(at)gmail(dot)com> wrote:

> So if I wanted to extend a column from 100 characters to 255 characters is
> this permitted? The fact that I'm not making a change and the BDR kicked me
> out makes me skeptical.
>

Off the top of my head I'm not sure and would need to test. There's no
specific logic in there for detecting such changes and permitting them, so
I suspect not.

If you're changing types in BDR you're expected to do it the long way. Add
a new col, update to copy the data, drop the old col and rename the new
col. Yes, that's ugly. We'd like to change it at some point. If you find
this particular problem annoying enough it'd be helpful if you could send a
patch for bdr_commandfilter.c to detect and permit changes that only affect
a column's typmod.

In the specific case of varchar columns, personally I recommend just using
'text' and adding a CHECK constraint on length. That's what I do most
places, not just BDR.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tim van der Linden 2016-04-28 06:36:00 Re: Slow join over three tables
Previous Message John R Pierce 2016-04-28 03:54:46 Re: [NOVICE] Fwd: Process scheduling in postgres