Add block hash to primary keys in transactions, receipts and logs tables

[prathamesh0]

Part of #99

• Add block hash (header_id) field to receipt_cids and log_cids tables
• Add block hash to the primary keys and postgraphile triggers on transaction_cids, receipt_cids and log_cids tables
• Add indexes on receipt_cids and log_cids tables using header_id
• Make indexes on using cid and mh_key on transaction_cids non-unique

[i-norden]

Thanks! Looks good, a few things to add:

On lines 17 and 18 of 00014, the indexes on eth.transaction_cids (mh_key, block_number) and (cid, block_number) need to be made non-unique. Or header_id needs to be added to the index, but I think we should just make the existing constraints non-unique.

And I think we need to add header_id to the eth.access_list_elements table and its PK as well.

[prathamesh0]

@i-norden

the indexes on eth.transaction_cids (mh_key, block_number) and (cid, block_number) need to be made non-unique

Changes incorporated.

And I think we need to add header_id to the eth.access_list_elements table and its PK as well.

Even if a transaction is part of two blocks at the same height, the access_list_elements entries are the same in both cases.
And if a transaction is part of two blocks at different heights, the access_list_elements entries are already being distinguished by block_number.
So unless I'm missing something, I think header_id is not really required to be part of access_list_elements table.
We can still add it if you think it might be helpful / avoid any issues in the future.

[i-norden]

So unless I'm missing something, I think header_id is not really required to be part of access_list_elements table. We can still add it if you think it might be helpful / avoid any issues in the future.

No you're right, that makes sense! The only way I see us needing it in the future is if we went back to using FKs- we'd need header_id in the access_list table in order for it to FK reference transaction_cids. But I don't think there is any intention of going back.