Re: Check constraint on foreign table using SQL function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Ulbrich <andreas(dot)ulbrich(at)matheversum(dot)de>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Check constraint on foreign table using SQL function
Date: 2014-12-25 17:27:56
Message-ID: 13474.1419528476@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Andreas Ulbrich <andreas(dot)ulbrich(at)matheversum(dot)de> writes:
> Questions:
> Wy is the check constraint function in a select called?
> The search_path seams not to be set for the SQL function, is this
> behavior correct?

Like Adrian, I'm a bit suspicious whether this test script is creating
the objects in the schema you think it is. It might be all right as
long as you execute it as user "andreas", but certainly not without that.

Anyway, as far as your second question goes, the postgres_fdw wrapper
intentionally forces the search_path to be just "pg_catalog" in its
remote session. We're aware that this breaks carelessly written
triggers and CHECK functions and so on, but really such functions
are broken anyhow; they should not be assuming anything about what
search_path they're called with.

As far as the first question goes, that shouldn't happen and in my
testing here I couldn't replicate it. So that fuels some suspicion
as to whether you're really accessing the table you think you are.
Maybe there's a view or something also named "tab_b"?

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2014-12-25 17:52:29 Re: Check constraint on foreign table using SQL function
Previous Message Adrian Klaver 2014-12-25 17:16:14 Re: Check constraint on foreign table using SQL function