From: Ashutosh B. <ash...@en...> - 2013-04-04 15:47:03
|
Hi Amit Here are comments on commit commit 1dc081ebe097e63009bab219231e55679db6fae0 Author: Amit Khandekar <ami...@en...> Date: Thu Apr 4 11:39:46 2013 +0545 A few helper functions needed for subsequent trigger-support related commits. In prologue of pgxc_check_triggers_shippability_ex() can you please use word "caller" instead of "user". "user" is confusing. Generally we keep all shippability related code in pgxcship.c. But I see trigger shippability code in trigger.c. Should we move it to pgxcship.c We may want to give a different name to function "pgxc_check_triggers_shippability_ex", since it's doing more than looking for shippability. The function is looking at all triggers for given command type to check if each of them is shippable. It also returns has_quals and trigger descriptor if requested. May be we want to call it as pgxc_relation_has_shippable_triggers() or something like that. BTW, mixing three functionalities 1. checking shippability of triggers on relation 2. returning a trigger descriptor for a relation 3. checking whether a trigger has quals, may not be a good idea (esp. putting 2 along-with 1 and 3). I can understand that it might improve performance a bit, because we save on lookup, but it will hamper readability, since we will be calling this function to get trigger descriptor even if we don't want shippability information. Can we please separate these functionalities into separate functions. A good example of misuse is function "pgxc_triggers_getdesc() which is a misnomer. This function gets trigger descriptor only if the triggers are unshippable and also returns this shippability status. Please add prologue to functions pgxc_form_trigger_tuple() and pgxc_get_trigger_tuple() to explain, what these functions do and where they can be used. -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Enterprise Postgres Company |