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.klaver@xxxxxxxxxxx
