Re: Foreign table permissions and cloning - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Foreign table permissions and cloning
Date
Msg-id 26531.1302838004@sss.pgh.pa.us
Whole thread Raw
In response to Re: Foreign table permissions and cloning  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Foreign table permissions and cloning  (Thom Brown <thom@linux.com>)
Re: Foreign table permissions and cloning  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Apr 1, 2011 at 5:13 AM, Thom Brown <thom@linux.com> wrote:
>> On 1 April 2011 12:57, Shigeru HANADA <hanada@metrosystems.co.jp> wrote:
>>> NOT NULL constraint on foreign table is just declaration and can't
>>> force data integrity.  And I noticed that CREATE FOREIGN TABLE
>>> document doesn't mention that serial and bigserial can't be used in
>>> foreign table.  Please see foreign_table_doc.patch for this fix.

>> I'd be inclined to generalise it to say that default values can't be
>> used on a foreign table, and then say that as a result, serial and
>> bigserial can't be used.

> +1.

Why is this a documentation issue and not a code issue?  IMO we should
flat out reject both NOT NULL and DEFAULT declarations on foreign
tables, until such time as we're prepared to do something useful with
them.  Reasons:

1. Accepting non-functional constraint declarations is something we've
been heard to ridicule mysql for.  With good reason.

2. It probably won't be too long before the planner makes optimization
decisions that assume NOT NULL declarations to be truthful.  When that
day comes, I don't want to be seeing an exception for foreign tables in
that logic.

3. When we do get around to making it actually work, we will have a
backwards-compatibility problem if prior versions accepted the
declaration but treated it as a no-op.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Single client performance on trivial SELECTs
Next
From: Jaime Casanova
Date:
Subject: Re: small bug in recoveryStopsHere()