From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: Deferrable unique constraints |
Date: | 2009-07-29 08:22:49 |
Message-ID: | 8e2dbb700907290122q1a5e2f2dga247c229abca9404@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2009/7/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Another thought on the index AM API issues: after poking through the
> code I realized that there is *nobody* paying any attention to the
> existing bool result of aminsert() (ie, did we insert anything or not).
> So I think that instead of adding a bool* parameter, we should repurpose
> the function result, along the lines of this spec:
>
> <para>
> The method's boolean result value is significant only when
> <literal>checkUnique</> is <literal>UNIQUE_CHECK_PARTIAL</>.
> In this case a TRUE result means the new entry is known unique, whereas
> FALSE means it might be non-unique (and a deferred uniqueness check must
> be scheduled). For other cases a constant FALSE result is recommended.
> </para>
>
And you'll be moving the ereport() back into the btree code? Makes
sense, provided that nothing is ever going to care whether the index
actually inserted an entry. I can see arguments for making the
recommended return value for "other cases" either TRUE or FALSE, but I
guess it doesn't matter since nothing is going to check it.
> <para>
> For non-unique indexes, it is not required that <function>aminsert</>
> do anything; it might for instance refuse to index NULLs.
> </para>
>
Doesn't this comment apply equally to unique indexes?
- Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Brendan Jurd | 2009-07-29 09:46:29 | Re: WIP: to_char, support for EEEE format |
Previous Message | Dean Rasheed | 2009-07-29 08:07:07 | Re: WIP: Deferrable unique constraints |