Re: rw_redis_fdw: SQL Errors when statement is within a function

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@aklaver.com