From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Rushabh Lathia <rushabh(dot)lathia(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Subject: | Re: NOT Null constraint on foreign table not working |
Date: | 2014-01-20 15:22:09 |
Message-ID: | 14362.1390231329@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-01-20 15:46:16 | Re: ALTER TABLESPACE ... MOVE ALL TO ... |
Previous Message | Stephen Frost | 2014-01-20 14:46:51 | Re: ALTER TABLESPACE ... MOVE ALL TO ... |