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

## GPT (gptmailinglists(at)gmail(dot)com):

> - In PG10.5 I run, out of function, a simple statement for 5 times
> successfully and the 6th time I get an error "KEY is NULL". In the
> meantime of these times I added, removed code, packages got updated,
> etc. Suddenly, an error. Key is NULL!!!??? Check the key, write
> statements to check the value of the key. Eh, it is not NULL! Hm, undo
> all changes, start again! Oh, now it runs! Ok, redo the changes one by
> one. Ah, ok still run. Suddenly, error again! Check again and again.
> Ok check Redis. Uninstall packages, reinstall packages... Finally,
> install PG9.6 make it run, install fdw to the new system, check the
> environment. OK run. Keep it as it is!

Your testing/debugging/validating processes seem to be a little
erratic. Sometimes it does make sense to build minimal test cases;
and to understand why things don't work or seem to be working again.

> So, in order this thread to get over:
> - PG developers made a drastic change. Not problem at all, more then welcome.
> - I was the "lucky guy" who had a painful experience. These things
> happen as Adrian wrote, and life goes on.

Let me add another thing here: you're using software which is marked
as "not really ready" (rw_redis_fdw/README.md: "work in progress and may
have experience significant changes until it becomes stable") which
uses very low level, internal interfaces to PostgreSQL; in a perhaps
not-trivial project (there's PostgreSQL, Redis, rw_redis_fdw, you mentioned
node.js and microservices...). I'm not sure you really did calculate the
project risk of that. In some environments, such setup are called
"technology jenga": deep stack with an unstable equilibrium.

> What I would like to ask from developers is:
>
> Please, if possible improve the error system!
>
> Especially when there are internal changes which may affect
> dynamically the outcome (from expected results to ERROR or whatever)
> of a correct statement.

I'm not sure we can do very much when external (not under any of our's
control - I guess most people here wouldn't even have known about
rw_redis_fdw until you mentioned it) components use interfaces in
a fragile way. And as it was noted several times: the developer of
that component identified the problem with the debug output (nothing
fancy here) and fixed it.

Regards,
Christoph

--
Spare Space