Re: Constraint using a SQL function executed during SELECT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Cyril B(dot)" <cbay(at)excellency(dot)fr>
Cc: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Constraint using a SQL function executed during SELECT
Date: 2016-07-19 14:27:49
Message-ID: 27416.1468938469@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Cyril B." <cbay(at)excellency(dot)fr> writes:
> On 07/19/2016 03:51 PM, Jim Nasby wrote:
>> In this example, you should be able to avoid that by setting
>> constraint_exclusion=off.

> Sorry I forgot to mention I had already tried that, to no avail.

Yeah, constraint_exclusion won't help, because this function isn't
in a CHECK constraint. It's in an index definition, and the planner
will always examine those.

My first reaction on looking at the example was that this particular
function shouldn't be a candidate for inlining, because it's not just
"SELECT expression". But I see that inline_function() runs parse analysis
before it checks for presence of a FROM clause, and that's when the
failure happens. Seems like it might be worthwhile to apply some of those
checks on the raw parsetree so that we could skip parse analysis when
there are obvious showstoppers like a FROM clause. This wouldn't
constitute a general solution to your problem, of course, but it would
save some useless cycles in planning.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Maeldron T. 2016-07-19 18:56:46 upsert with trigger (or rule)
Previous Message Greg Sabino Mullane 2016-07-19 14:17:54 Re: MediaWiki + PostgreSQL is not ready for production?