On Tue, Jan 21, 2014 at 9:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapila16@gmail.com> writes:
>> On Mon, Jan 20, 2014 at 8:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> There has been a great deal of debate about what constraints on foreign
>>> tables ought to mean.
>
>> What is the reason for keeping DEFAULT behaviour different than
>> constraints. Right now the behaviour for DEFAULT is if it is
>> defined on foreign table, then it will use that even if original table has
>> different or no default value?
>
> If you look back to the original thread about the writable-foreign-tables
> patch, we expended a lot of sweat on that point too. The ideal thing IMO
> would have been to allow the remote end's default specification to control
> what happens, but we found enough difficulties with that that we ended up
> punting and allowing the default expression to be evaluated locally.
> I'm not terribly satisfied with that result, but that's where we are.
okay, I think we can specify more clearly in documentation of Foreign Table
as right now it is bit difficult to get the right behaviour by reading
documentation. Another thing could be to return Syntax Error like it does
for other constraints like CKECK.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
