Re: SQL/MED - core functionality

On Tue, Dec 28, 2010 at 4:45 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 28.12.2010 05:16, Robert Haas wrote:
>> On Sat, Dec 25, 2010 at 11:52 PM, Robert Haas<robertmhaas(at)gmail(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.

It's true that we can't enforce the non-NULL-ness of data, but we also
can't enforce that the remote columns have any particular type, or
that the number of columns and their names match the remote side, or
indeed that the remote table exists at all. I think that the right
approach here is to declare that the entire foreign table definition
is essentially a contract. The user is promising us that the returned
data will match the supplied parameters. If it doesn't, the user
should expect errors and/or wrong answers.

On a practical level, getting rid of NOT NULL constraints will
pessimize many queries, and even more complex table constraints have
their uses. Adopting that as a project policy seems short-sighted.

>> - I removed all of the changes related to adding a HANDLER option to
>> foreign data wrappers.  I think that stuff properly belongs in the
>> "fdw scan" patch.  Instead, what I've done here is just prohibit
>> foreign data wrappers from being used in queries.  I'm generally
>> pretty negative on syntax-only patches, but then foreign data wrappers
>> have been basically syntax-only for two releases, and I think there's
>> a good chance that if we get the syntax patch in soon we'll actually
>> be able to make it work before we run out of time.  So I'm feeling
>> like it might be OK in this case, especially because even with all the
>> trimming down I've done here, this is still a very big patch.
>
> +1, now that we have a patch for the rest of the feature as well.

I think it's going to need some pretty heavy rebasing, over my changes
- but yes.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company