Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux