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
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 |