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

On 10/30/18 3:19 AM, GPT wrote:
> Very good morning!
>
> If, in 2018 when the human structures are very close to reach the edge
> of our universe, here on earth you are asking me (a simple end-user),
> in order to run the following "complicated" and "sophisticated" SQL
> statements:
>
> INSERT INTO my_table(key, value, expiry) VALUES ('my_key', 'my_value', 10);
> SELECT value FROM my_table where key = LOWER('my_key');
>
> ten (10) times in total, to activate the debugger and check the log
> files because the errors given to me were **totally wrong** ("KEY is
> NULL" was not NULL) and **misleading**, then one more time: It´s
> TRAGIC!
>
> I, of course, recognise that I have made plenty mistakes! But, I could
> never imagine that the most advanced open source database in the world
> would behave in such a "poor" way!

Postgres did not behave in a 'poor' way, the extension just did not
interpret the results correctly. This gets to the crux of the problem,
third party code using Postgres. Postgres has no way of knowing what
happens after its data is passed on. 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. You did
the correct thing, report the issue to the extension author and post to
this list for further advice. As a result the issue was corrected. I am
not seeing what the problem in the process is?

>
> @Christoph
>
> As regards "rw_redis_fdw" I have to admit the following:
> - it is honest. It informs the user from the very beginning that "This
> project is currently work in progress and may have experience
> significant changes until it becomes stable. Use it with caution and
> at your own risk!"; although it is so far stable enough!!!
> - it worked in pg9.x without problem!
> - the developer did his best when I reported the problem; for my bad
> luck he did not expirienced the same problem in PG10.x so as he starts
> searching/debugging from the very first moment.
> - after **including and NOT fixing** (because there was not any bug)
> the FuncExpr subquery support, the module has been working fine and it
> is stable! (until of course the next plan change that PG will induce
> under the hood and brakes the interface; that´s a joke!) although the

It is not a joke it is a fact of life and the reason for major version
changes. They are allowed to make breaking changes in the code. It is
how software progresses. It is also why there is a long testing period,
alpha-->beta-->rc, to give users and third party developers plenty of
opportunity to try their code against the changes.

> developer uses (successfully - I add) very low level, internal
> interfaces to PostgreSQL as you have already written.
>
> And the most important:
>
> <h1>The module **DOES** whatever claims to do without a problem, in a
> very humble way!<h1>

Except the problem you ran into:)

>
> As regards the risk of the project, I am aware of it. That´s why I am
> trying to choose **reliable**, **responsible** and **trustworthy**
> projects, even if they are not famous! From a very famous project, I
> just recently got a burn! Do only **ONE** thing but do it
> **"CORRECTLY"**! I always try to avoid rich-featured projects which,
> by rule, most of the features are mis-implemented, or quality is poor!
>
> As regards database choice, I do not have many options, PG or MariaDB
> or SQLite. But, when the application is finished, it will be very easy

There is also:

http://www.firebirdsql.org/
https://www.mysql.com/

> to maintain the application-DB interface and use any other DB. It is a
> matter of translation. DB is just a tool like any other one, and not a

Which is exactly where you ran into a problem, so I question the easy
part. Still, go for it.

> religous matter.
>
> In the case of redis fdw I do not have many options. There are
> two-three of them. Redis is the only db which offers TTL with very
> high resolution (1 sec), and rw_redis_fdw implements TTL.
>
> In addition, at first opportunity, I always contact the developer or
> the community to get an idea of his/its mentality and the way they
> work or react or keep their nose up.

Pretty quickly from what I saw of their responses to your issues.

>
> Have all a nice day!
>
> Tia
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com