* Dean Rasheed (dean.a.rash...@gmail.com) wrote: > One improvement we could trivially make is to only do this for > multi-column indexes. If there is only one column there is no danger > of information leakage, right?
That's an interesting thought. If there's only one column then to have a conflict you must be changing it and providing a new value with either a constant, through a column on which you must have select rights, or with a function you have execute rights on. So, no, I can't think of a way that would leak information. I'm still on the fence about it though as it might be confusing to have single-column indexes behave differently and I'm a bit worried that, even if there isn't a way now to exploit this, there might be in the future. > Yeah I couldn't see any easy way of doing it. 2 possibilities sprung > to mind -- (1) wrap the index update in a PG_TRY() and add the detail > in the catch block, or (2) track the currently active EState and make > GetModifiedColumns() into an exported function taking a single EState > argument (the EState has the currently active ResultRelInfo on it). > Neither of those alternatives seems particularly attractive to me > though. The EState is available when dealing with exclusion constraints but it's not available to _bt_check_unique easily, which is the bigger issue. GetModifiedColumns() could (and probably should, really) be moved into a .h somewhere as it's also in trigger.c (actually, that's where I pulled it from :). Thanks, Stephen
signature.asc
Description: Digital signature