Re: Foreign table permissions and cloning

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thom Brown <thom(at)linux(dot)com>, Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Foreign table permissions and cloning
Date: 2011-04-15 03:26:44
Message-ID: 26531.1302838004@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Apr 1, 2011 at 5:13 AM, Thom Brown <thom(at)linux(dot)com> wrote:
>> On 1 April 2011 12:57, Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2011-04-15 05:26:04 Re: small bug in recoveryStopsHere()
Previous Message Tom Lane 2011-04-15 03:16:03 Re: Single client performance on trivial SELECTs