-
Roy Lyseng authored
We have recently done significant refactoring to ensure that the objects TABLE_LIST::grant and TABLE::grant are kept synchronized for a specific use of a table. This patch goes one step further by removing the TABLE::grant object and relying solely on TABLE_LIST::grant. The obvious benefits are less work, and less complexity to keep the two objects synchronized. Implementation is straightforward, except for the HANDLER interface which uses two TABLE_LIST objects to manage a table. Solution here is the simplest possible (keep the two GRANT objects synchronized), since cleanup of HANDLER is not prioritized. Notice also that columns specified in HANDLER READ statements cannot be privilege checked due to bug no. 25987758, however this is not critical as all columns are nevertheless checked by insert_fields(). Pay attention to the big if statement in insert_fields() that proved to be far too complex and pretty misleading.
Roy Lyseng authoredWe have recently done significant refactoring to ensure that the objects TABLE_LIST::grant and TABLE::grant are kept synchronized for a specific use of a table. This patch goes one step further by removing the TABLE::grant object and relying solely on TABLE_LIST::grant. The obvious benefits are less work, and less complexity to keep the two objects synchronized. Implementation is straightforward, except for the HANDLER interface which uses two TABLE_LIST objects to manage a table. Solution here is the simplest possible (keep the two GRANT objects synchronized), since cleanup of HANDLER is not prioritized. Notice also that columns specified in HANDLER READ statements cannot be privilege checked due to bug no. 25987758, however this is not critical as all columns are nevertheless checked by insert_fields(). Pay attention to the big if statement in insert_fields() that proved to be far too complex and pretty misleading.
Loading