Re: CREATE FOREGIN TABLE LACUNA

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CREATE FOREGIN TABLE LACUNA
Date: 2012-03-14 20:44:34
Message-ID: 5237.1331757874@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On ons, 2012-03-14 at 10:27 -0400, Tom Lane wrote:
>> That opinion seems to me to connect to the recently-posted patch to
>> make contrib/file_fdw enforce NOT NULL constraints. Should we instead
>> have the position that constraints declared for foreign tables are
>> statements that we can take on faith, and it's the user's fault if
>> they are wrong?

> We should look into the NOT ENFORCED stuff for constraints in SQL:2011.
> Then we can have both, and both for regular and foreign tables.

Have both what? The key point here is that we *can't* enforce
constraints on foreign tables, at least not with anything like the
semantics SQL constraints normally have. Ignoring that point leads
to nonsensical conclusions.

Declaring a foreign constraint as NOT ENFORCED might be a reasonable
thing to do, but it doesn't help us decide what to do when that clause
isn't attached.

On reflection I don't see anything much wrong with the "if you lied
about the constraint it's your fault that things broke" position.
It seems quite comparable to the fact that we take the user's assertions
on faith as to the number and data types of the columns in a foreign
table.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2012-03-14 20:48:28 Re: CREATE FOREGIN TABLE LACUNA
Previous Message Andrew Dunstan 2012-03-14 20:43:55 Re: Faster compression, again