Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group