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

Good evening,

Thanks for the response.

On Wed, Oct 31, 2018, 2:59 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)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(dot)klaver(at)aklaver(dot)com
>