Re: NOT Null constraint on foreign table not working - Mailing list pgsql-hackers

From Tom Lane
Subject Re: NOT Null constraint on foreign table not working
Date
Msg-id 12199.1390276973@sss.pgh.pa.us
Whole thread Raw
In response to Re: NOT Null constraint on foreign table not working  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: NOT Null constraint on foreign table not working  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
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.

Another thing to keep in mind is that the preferred behavior isn't
necessarily the same for every FDW.  If there isn't a remote SQL server
underlying a foreign table (think file_fdw for instance) then you might
end up with different choices about what defaults and constraints mean.

We basically ran out of time to deal with these issues back in 9.3.
It'd be worth thinking through a holistic proposal about how it ought
to work across a range of FDW types.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: WIP patch (v2) for updatable security barrier views
Next
From: Amit Kapila
Date:
Subject: Re: NOT Null constraint on foreign table not working