| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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-15 18:29:08 |
| Message-ID: | 1331836148.22067.3.camel@vanquo.pezone.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On ons, 2012-03-14 at 17:38 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On ons, 2012-03-14 at 17:16 -0400, Robert Haas wrote:
> >> If a constraint is NOT ENFORCED, then the query planner presumably
> >> won't rely on it for planning purposes
>
> > Why do you presume that?
>
> What does SQL:2011 say exactly about the semantics of NOT ENFORCED?
> Is an implementation allowed to fail in undefined ways if a constraint
> is marked NOT ENFORCED and is not actually true?
It doesn't say anything about that. I might have to dig deeper into the
change proposals to see if any rationale came with this change.
But in any case, even if we spell it differently, I think there are use
cases for a constraint mode that says, assume it's true for optimization
purposes, but don't spend any cycles on verifying it. And that
constraint mode could apply to regular tables and foreign tables alike.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-03-15 18:31:06 | Re: pg_upgrade and statistics |
| Previous Message | Peter Eisentraut | 2012-03-15 18:20:52 | Re: pg_upgrade and statistics |