| From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
|---|---|
| To: | "Rushabh Lathia *EXTERN*" <rushabh(dot)lathia(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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-21 08:08:17 |
| Message-ID: | A737B7A37273E048B164557ADEF4A58B17C915E9@ntex2010i.host.magwien.gv.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Rushabh Lathia wrote:
> 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.
I believe that a column of a foreign table should be NOT NULL only if
it is guaranteed that it cannot contain NULL values. Doesn't the planner
rely on that?
But PostgreSQL cannot guarantee that, that has to happen on the remote side
(or in the FDW). I think that it is best that an error for a constraint
violation is thrown by the same entity that guarantees that the constraint
is respected.
So I agree with your last statement.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2014-01-21 08:19:59 | Re: proposal: hide application_name from other users |
| Previous Message | Peter Geoghegan | 2014-01-21 07:30:35 | Re: Performance Improvement by reducing WAL for Update Operation |