From: | Euler Taveira <euler(at)timbira(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: NOT NULL constraints in foreign tables |
Date: | 2012-08-17 23:08:49 |
Message-ID: | 502ECF01.7090206@timbira.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 17-08-2012 16:44, Robert Haas wrote:
> On Fri, Aug 17, 2012 at 2:58 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
>> I mean, what are NOT NULL in foreign tables for? Are they harmed or
>> helped by having pg_constraint rows?
>
> As I've mentioned when this has come up before, I think that
> constraints on foreign tables should be viewed as declarative
> statements about the contents of the foreign data that the DB will
> assume true. This could be useful for a variety of purposes:
> constraint exclusion, query optimization, etc.
>
+1. I don't see us providing a mechanism to cross-check changes between data
sources. Even if we do it for creation time, schema could be changed behind
the scenes. Let's use at least constraints (NOT NULL, CHECK, UNIQUE, PK --
UNIQUE + NOT NULL) to improve optimizer but warn (loudly) that those
constraints are merely for optimization.
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-08-18 01:46:55 | New WAL code dumps core trivially on replay of bad data |
Previous Message | johnlumby | 2012-08-17 22:28:31 | asynchronous disk io (was : tuplesort memory usage) |