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
