* Dean Rasheed (dean.a.rasheed@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