Re: Avoid FK validations for no-rewrite ALTER TABLE ALTER TYPE

From: Noah Misch <noah(at)leadboat(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoid FK validations for no-rewrite ALTER TABLE ALTER TYPE
Date: 2012-01-26 03:39:56
Message-ID: 20120126033956.GC15670@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 25, 2012 at 11:17:27AM -0300, Alvaro Herrera wrote:
>
> Excerpts from Noah Misch's message of dom ene 22 02:05:31 -0300 2012:
>
> > Thanks. I've attached a new version fixing this problem.
>
> Looks good to me. Can you please clarify this bit?
>
> * Since we elsewhere require that all collations share the same
> * notion of equality, don't compare collation here.
>
> Since I'm not familiar with this code, it's difficult for me to figure
> out where this "elsewhere" is, and what does "same notion of equality"
> mean.

Good questions. See the comment in front of ri_GenerateQualCollation(), the
comment in process_ordered_aggregate_single() at nodeAgg.c:605, the larger
comment in add_sort_column(), and the two XXX comments in
relation_has_unique_index_for(). We should probably document that assumption
in xindex.sgml to keep type implementors apprised.

"Same notion of equality" just means that "a COLLATE x = b COLLATE y" has the
same value for every x, y.

In any event, the patch needed a rebase, so I've attached it rebased and with
that comment edited to reference ri_GenerateQualCollation(), that being the
most-relevant source for the assumption in question.

Thanks for reviewing,
nm

Attachment Content-Type Size
at-foreign-key-v4.patch text/plain 16.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2012-01-26 04:03:20 cursors FOR UPDATE don't return most recent row
Previous Message Noah Misch 2012-01-26 02:51:13 Re: Second thoughts on CheckIndexCompatible() vs. operator families