On Mon, Jan 20, 2014 at 8:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Rushabh Lathia <rushabh.lathia@gmail.com> writes: > As per the PG documentation it says that foreign table do support the > NOT NULL, NULL and DEFAULT.
There has been a great deal of debate about what constraints on foreign tables ought to mean. Right now, at least for postgres_fdw, they're just taken as documentation of constraints that are supposed to exist on the far side. It's not clear what's the point of trying to enforce them against insertions done locally if the remote table lacks them --- any table update done on the far side could still violate the constraint.
We might change this in response to a well-reasoned argument, but it won't happen just because somebody lobs a quick-and-dirty patch over the fence.
If we were going to enforce them locally, I'd opine it should be the FDW's task to do it, anyway. It might have more knowledge about the best way to do it than nodeModifyTable.c can, and if not it could still call ExecConstraints for itself.
Submitted patch was never intended to get checked in without the proper discussion
and decision about what behaviour should be for foreign table constraint. Sorry if I
passed wrong message but was never intended.
I found constraints on foreign table is very useful for the application when the multiple
user accessing same remote table using fdw and both user want to enforce different
constraint on particular table or different user want to enforce different DEFAULT
expression for the same table column.
I agree with you that if we want to enforce constraint locally then it should be
FDW's task to do it rather then nodeModifyTable.c.