Very good morning, Thanks very much for your direct, clear and enlightening response! As regards Q2, and any other dynamic behaviour/feature or whatever PG includes or will include in the future and has to do with 3rd entities (modules, or whatever) of which the behaviour is out of the PG control, safe precautions would be take easily, in favour of the passive protection of the end-user, and the good reputation of PG (consider the last as marketing cookie addressed to the commercial community ;) ). For example: in the .control file more fileds would be added to clarify dynamic manners/behaviours/communications. For example: subexpr_type = T_Param, T_RelabelType So, when a module (which makes use of internal parts of PG) is created, those parameters are recorded in the DB. When the 3rd party initiates an activity/communication with PG, PG checks this parameters and behaves/responds to a compatible manner that 3rd party always understands. A warning about an old-fashion parameter value would be triggered by PG in every communication instance (or not) to inform the user/developer that something has changed/improved! When such a message/warning is seen by them, then they can easily add the new feature, such as T_FuncExpr, after, of course, the code has been updated properly, to declare the support. So, PG continues being developed under the hood, retains backward compatibility without any real cost and retains the operability of the 3rd entities improving, at the same time, the control on them (and the eco-system, in general), and end-users are protected, too! Tia
