Re: Proposed feature: Selective Foreign Keys

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tom Dunstan <pgsql(at)tomd(dot)cc>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposed feature: Selective Foreign Keys
Date: 2013-12-03 02:07:33
Message-ID: 29679.1386036453@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Dunstan <pgsql(at)tomd(dot)cc> writes:
> Well, with this patch, under the hood the FK query is doing (in the case of RESTRICT):

> SELECT 1 FROM ONLY "public"."comment" x WHERE (the id) OPERATOR(pg_catalog.=) "parent_id" AND (parent_entity = 'event') FOR KEY SHARE OF x;

Hm. The RI trigger code goes to extreme lengths to make sure that the
query strings it generates will invoke exactly the operators it intends
--- thus the OPERATOR(pg_catalog.=) syntax, which would otherwise be
merely overkill. The added text you are showing above seems trivially
vulnerable to unwanted behavior and even security bugs, if executed in
say an unexpected search_path context. I am not sure that we have the
technology to automatically make arbitrary expressions proof against that
sort of hazard, but in any case you don't seem to be trying very hard.

Another issue that would need to be thought about is trojan-horse
functions in the WHERE clause. IIRC, RI trigger queries might run as the
owner of either the referencing or the referenced tables. If those two
don't fully trust each other then this is opening the gates for mischief.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Dunstan 2013-12-03 02:18:20 Re: Extension Templates S03E11
Previous Message Tom Lane 2013-12-03 01:56:03 Re: UNNEST with multiple args, and TABLE with multiple funcs