On Tue, Dec 28, 2010 at 18:45, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
>> In fact, basically all you can do with CREATE FOREIGN TABLE is set column
>> names, types, and whether they're NOT NULL. But I think that's enough
>> to get started.
>
> Even NOT NULL seems questionable. It might be interesting for the planner,
> but our cost estimates of remote queries are pretty bogus anyway. We can't
> enforce the NULLness of remote data, so I don't think we should allow NOT
> NULL, and should always choose plans that are safe if there are NULLs after
> all.
The same can be said for CHECK constraints, but CHECKs on foreign tables are
very useful to support multi-nodes partitioning. So, I'd like to support
CHECKs even though we cannot enforce the constraints at remove servers.
Will we have CHECKs but drop NOT NULLs?
Another idea is to have an option to apply those constraints at SELECT.
We can find corrupted foreign data at that time.
--
Itagaki Takahiro
