Re: [PATCHES] schema-qualified SET CONSTRAINTS

From: Kris Jurka <books(at)ejurka(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] schema-qualified SET CONSTRAINTS
Date: 2006-04-11 20:30:18
Message-ID: Pine.BSO.4.63.0604111509030.29104@leary2.csoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Mon, 10 Apr 2006, Tom Lane wrote:

> Kris Jurka <books(at)ejurka(dot)com> writes:
>> The attached patch allows SET CONSTRAINTS to take a schema qualified
>> constraint name (myschema.t1_fk_t2) and when given a bare constraint name
>> it uses the search_path to determine the matching constraint instead of
>> the previous behavior of disabling all identically named constraints.
>
> This patch seems egregiously non backwards compatible :-(.

Yes, it does change the existing behavior, but "egregiously"? How many
applications intentionally defer constraints in multiple schemas at once?
Not many. I would guess the more likely situation is that these
applications don't even realize that they are deferring more than one
constraint when it happens. So there will be some very minor pain when
they must select the desired constraint (if it doesn't happen already by
search_path) or explicitly defer more than one constraint, but I'm OK
with that. The existing behavior of SET CONSTRAINTS affecting everything
is not what a user would expect when we have tools like search_path
available.

Kris Jurka

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-04-11 20:35:05 Re: plpgsql by default
Previous Message Jim C. Nasby 2006-04-11 20:13:02 Re: plpgsql by default

Browse pgsql-patches by date

  From Date Subject
Next Message Jim C. Nasby 2006-04-11 20:38:58 OS cached buffers (was: Support Parallel Query Execution in Executor)
Previous Message Guillaume Smet 2006-04-11 19:57:48 Re: Patch proposal for log_duration