Bruce Momjian wrote:
> Jan Wieck wrote:
>> Unfortunately I don't think it'll get there ever. There is a fundamental
>> design flaw in the system that is not fixable (there are multiple, but
>
> I was wondering about this. It seems to be part of our existing problem
> with handling unique contraints during the query, rather than at query
> end or transaction end:
>
> [...]
>
> Another idea would be to only queue up the unique constraint failures,
> and re-check on transaction commit --- that way, you only have a queue
> when you have a possible unique constraint violation, and you re-check
> at the end.
>
_That_ actually is _the_ idea I was missing!
During index insert I think we know everything that needs to be known.
We know the index in question, which definitely leads to the relation in
question. And we know the CTID of the new heap tuple containing the key
values in conflict. IIRC that is enough to schedule some sort of
[DEFERRED] AFTER INSERT trigger ... one more of these generic C monsters.
Some sort of, because it's call interface might be a bit different. We
won't have a pg_trigger row for it anywhere. But since it'd be a generic
function for all index dupkey checks, I wouldn't mind much to hardwire
it into the trigger queue.
The trigger actually only needs to do a
SELECT 1 FROM <rel> WHHERE <full qualification>
That over SPI_execp() with a tupcount of 2 and it'll be it. Maybe it
needs to do it FOR UPDATE to have the correct visibility and locking,
but that's a minor implementation detail.
Cool!
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
