Re: SQL/MED - core functionality

From: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SQL/MED - core functionality
Date: 2010-12-28 10:23:43
Message-ID: AANLkTikCetbpYu83t6EJwXfGTa3bo-A7v+saAc6Q-jvQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 28, 2010 at 18:45, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Urbański 2010-12-28 11:25:48 Re: autogenerating error code lists (was Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.)
Previous Message Jie Li 2010-12-28 10:13:40 small table left outer join big table