Thank you for the message Tom; sounds great. I'll try that out, will check on the planner's resultant behavior and email back.
Peter On Sat, May 23, 2015 at 12:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Swartz <peter.goodings.swa...@gmail.com> writes: > > suppose the foreign database adds a value to the enum, and the foreign > > table now has rows with this new value, while the local definition of the > > enum remains unchanged. Obviously, the appropriate action on my part is > to > > maintain consistency of enum definition between the foreign and local > > database, but I'm curious about what behavior would result if there was > an > > error in this manual updating process. > > What I'd expect to happen is that you'd get errors when retrieving rows > that had the values not known on the local side. > > One potential way around this is to declare the foreign table's columns > as "text" rather than enums; you would lose some error checking on the > local side, but the remote server would enforce validity whenever you > stored something. (But I'm not sure whether this hack behaves desirably > for WHERE conditions on the enum column; you'd need to test.) > > regards, tom lane >
