{"push_id":2520913778,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"1f23ea725597207dd68b330876f56850a05e84f5","before":"f123254034c524eb6ba79538660298a2c7c455c7","commits":[{"sha":"1f23ea725597207dd68b330876f56850a05e84f5","author":{"name":"Kuntal Ghosh","email":"b68f9f124b4a2325262a7beb27dae42d45f1181c@enterprisedb.com"},"message":"Implement Foreign Key Constraint for zheap\n\nFor zheap, when we call the triggers we convert a zheap tuple to heap\ntuple. But, we don't store any transaction related information on the\nheap tuple. Hence, I've to make the following two\nassumptions/considerations for the foreign key implementation in\nzheap:\n\n1. RI_FKey_fk_upd_check_required: In this function, we check if the\noriginal row was inserted by our own transaction, we must fire the\ntrigger whether or not the keys are equal. For zheap, since we don't\nhave the transaction related information, we always fire the trigger.\nSo, even if the keys are equal, we cannot skip the trigger for zheap.\n\n2. validateForeignKeyConstraint: During ALTER TABLE..ADD CONSTRAINT\nFOREIGN KEY, this function is called to validate whether we can add\nthe foreign key constraint. First, it tries to fire a LEFT JOIN query\nto test the validity. If the user doesn't have proper access rights to\npktable/fktable, we scan the table in pagescanmode and fire trigger\nfor each tuple. Before firing the trigger, it takes buffer lock to\ncheck whether it can skip the trigger. For zheap, we don't retain the\npin on the buffer. Hence, we've to read the buffer again before\nlocking the same.\n\nPatch by me, Reviewed and tested by Ashutosh Sharma","distinct":true,"url":"https://api.github.com/repos/EnterpriseDB/zheap/commits/1f23ea725597207dd68b330876f56850a05e84f5"}]}
{"actor":{"display_login":"kuntalghosh"}}