Re: rw_redis_fdw: SQL Errors when statement is within a function - Mailing list pgsql-general

From Adrian Klaver
Subject Re: rw_redis_fdw: SQL Errors when statement is within a function
Date
Msg-id 0cfe9381-ee97-7c29-baad-28fbda0480a1@aklaver.com
Whole thread Raw
In response to Re: rw_redis_fdw: SQL Errors when statement is within a function  (GPT <gptmailinglists@gmail.com>)
Responses Re: rw_redis_fdw: SQL Errors when statement is within a function
List pgsql-general
On 10/30/18 9:15 AM, GPT wrote:
> Good afternoon!
>> ...
>> Postgres did not behave in a 'poor' way, the extension just did not
>> interpret the results correctly.
> Eh! Eh! Adrian/Christoph one minute please because this is something
> new (at least in the very clear way you formulate it now and I can
> understand it easily)!
> The statement was sent correctly from the module to PG; PG returned
> the correct set of data to the module; BUT module failed to
> interpret/present the data to me!
> 
> Q1: Is this what you are telling me?
>    a) Yes
>    b) No

a) Yes

> 
> Q2: Module sent the statement to the PG in a way A which PG does
> understand. Did the PG sent back to the module in a way A or B or ...
> which module understands?
>    a) Yes
>    b) No

Not sure of exactly where the breakdown in communication happened, that 
would need input from the extension developer. From what I gather the 
extension reparse's the query at some point and failed to take into 
account that the internal representation of the query may change after a 
number of repetitions of the query.



> 
> Q3: And which part has "triggered" (so, is responsible for) the wrong
> errors to appear on my screen,
>    a) PG,
>    b) the module,
>    c) the java driver,
>    d) PL/SQL,
>    e) undefined,
>    f) NULL or
>    g) I do not know / I do not respond (joke!)?

b) the module.

See below for explanation:
https://github.com/nahanni/rw_redis_fdw/commit/05f5f3247569e6c428360cc4270606a91e57c6ff


> 
>>
>> ... Postgres has no way of knowing what
>> happens after its data is passed on.
> In this case, I do not disagree at all!
>>
>> 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.
> 
> Q4: If I used psql, I would get the correct data or not?

The query would run correctly, you would not be able to move data to 
Redis though.

>>
>> You did ... I am
>> not seeing what the problem in the process is?
> There is not any problem in the process at all. The process is
> excellent. Now, I realise that our communication channels/frequencies
> maybe are different. We have exchanged so many mails because we are
> not able to understand each other.
>>
>> ...
>> It is not a joke ...
> I do agree! That's why I said it's a joke! Ah, again different frequencies.
>>
>> ...
>> Except the problem you ran into:)
> + Eh, "you" added the new plan! Don't be unfair to the developer!

Not trying to be unfair, just pointing out things change and code needs 
to be tested against the changes.

>>
>> ...
>> There is also:
>>
>> http://www.firebirdsql.org/
>> https://www.mysql.com/
> There are more! Eh eh! "You" fooled me by writing that it is the most
> advanced open source database in the world! I believed in "you" and
> "your" words!

That is the projects motto, it has nothing to do with me:)

> Mysql site writes "The world's most popular open source database". I
> am not gonna get fooled again so easily!

I see motto's/slogans as marketing and I consider most marketing as a 
form of lying.

>>
>> ...
>> Which is exactly where you ran into a problem, so I question the easy
>> part. Still, go for it.
> I do not get it! Different frequencies...

I was referring to this:

"But, when the application is finished, it will be very easy
to maintain the application-DB interface and use any other DB. It is a
matter of translation."

The problem you had was a matter of translation. Translation is always 
going to be tricky, especially the more translations you have to do in a 
project.

>> ...
>> Pretty quickly from what I saw of their responses to your issues.
> The enlightenment has not been quickly but easy easy we shall manage
> to become together!
>>
> Have a nice evening!
> 
> Tia
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com


pgsql-general by date:

Previous
From: Martin Mueller
Date:
Subject: Re: editable spreadsheet style interface
Next
From: Adrian Klaver
Date:
Subject: Re: Question about servicescript for stopping and starting postgresqlinstance