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: Index AM API changes for deferability |
Date: | 2009-07-18 10:09:54 |
Message-ID: | 8e2dbb700907180309h42167ca1wd5f12dc2fde9ee26@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2009/7/15 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> There is no reason at all to avoid an index AM API change if one is
> useful.
Thinking about this a bit more, perhaps it would be better if I added
an out parameter to the AM for the uniqueness result, rather than
overloading the return value, which is quite ugly:
bool
index_insert(Relation indexRelation,
Datum *values,
bool *isnull,
ItemPointer heap_t_ctid,
Relation heapRelation,
IndexUniqueCheck uniqueness_check,
bool *is_unique);
This would allow me to tidy up some of the code I added to
ExecInsertIndexTuples() which is a bit of a kludge to support
the hash indexes enforcing uniqueness in the future:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00812.php
Also I could then move the ereport() for unique key violations from
_bt_check_unique() into index_insert() which would allow the
Duplicate key value error patch to be non-btree-specific:
http://archives.postgresql.org/message-id/20090403161658.AFB2.52131E4D@oss.ntt.co.jp
http://archives.postgresql.org/message-id/24655.1238885884@sss.pgh.pa.us
Thoughts?
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-07-18 10:13:19 | Re: MIN/MAX optimization for partitioned table |
Previous Message | Pavel Stehule | 2009-07-18 09:26:58 | Re: mixed, named notation support |