Good evening, Thanks for the response.
On Wed, Oct 31, 2018, 2:59 PM Adrian Klaver <adrian.kla...@aklaver.com wrote: > On 10/31/18 2:03 AM, GPT wrote: > > 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! > > The short version: > > The above is not going to happen. > > The long version: > > 1) You are asking Postgres to do what previously you said you did not > want it to do: > > > https://www.postgresql.org/message-id/CADep2PMJVpVu-ne42yYpqjzGHQ1cunvX92Oo6_hNLfgrj%2BMa_Q%40mail.gmail.com > > " You are looking for Postgres to > > follow its responses all the way through the software stack and tell you > > if the response is being misused. That is not going to happen. > For God sake! No, I am not! As soon as the correct data left the > PG-space in the format that the statement requested, and the KEY was > not NULL, of course, I do not blame PG." > > > 2) Trying to track the state of every third party code that hits a > database and it's internal diff from the current internal state of the > Postgres database code would be intensive and intrusive, for little or > no benefit in all but a few cases. Those few cases are better dealt with > by the existing process of issue reporting. > > 3) Having said 1) and 2) Postgres does do a limited version of what you > want: > > https://www.postgresql.org/docs/11/static/protocol.html > > "This document describes version 3.0 of the protocol, implemented in > PostgreSQL 7.4 and later. For descriptions of the earlier protocol > versions, see previous releases of the PostgreSQL documentation. A > single server can support multiple protocol versions. The initial > startup-request message tells the server which protocol version the > client is attempting to use. If the major version requested by the > client is not supported by the server, the connection will be rejected > (for example, this would occur if the client requested protocol version > 4.0, which does not exist as of this writing). If the minor version > requested by the client is not supported by the server (e.g. the client > requests version 3.1, but the server supports only 3.0), the server may > either reject the connection or may respond with a > NegotiateProtocolVersion message containing the highest minor protocol > version which it supports. The client may then choose either to continue > with the connection using the specified protocol version or to abort the > connection." > > Though it should be noted the above is for the public API, not the > private parts your extension had a problem with. They are > private(internal) for a reason. If code needs to touch them then the > developer becomes responsible for keeping up to date with their changes. > > 4) 3) also addresses the backwards comparability issue as the current > protocol extends back to 7.4, which went EOL of life 8 years ago. > > > > > > Tia > > > > > -- > Adrian Klaver > adrian.kla...@aklaver.com >
