Tom Lane wrote:
As an example, the present patch imagines that it will have adequate control over inserts by putting hooks into simple_heap_insert and the (rather small number of) places that call heap_insert directly. But there are dozens of calls of simple_heap_insert and no way for the function itself to know why it is being called or on whose behalf. The patch's hook function tries to work around the fact that it hasn't got that information by means of heuristics. Aside from the question of whether there are bugs in those heuristics today (I'm certain there are), every time we accept a patch that adds another call of simple_heap_insert, we're going to have to revisit the hook to see if it needs to be twiddled. Another problem is that since the hook only knows the parameters to simple_heap_insert plus global state (such as current_user), it can't cope very well with security-related context changes. We have already heard that situations involving views are simply broken in the patch as it stands --- row-level permissions are checked against current_user and not the view owner, and there's no good way to fix that.
Leaving aside any other issues, it seems to me that the chance of remedying these defects reasonably in a couple of weeks is just about nil.
That leaves the following questions: can the row-level part of the patch be separated out, and if so how easily, and is what would be left worth doing?
cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
