Good morning,
>> 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
Good evening,
Thanks for the response.
On Wed, Oct 31, 2018, 2:59 PM Adrian Klaver 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
> > i
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
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
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
unders
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
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(ke
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'
## GPT (gptmailingli...@gmail.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 th
On 10/29/18 3:58 AM, GPT wrote:
Hi, I had a wonderful Sunday, and have no intention to change that sense!
Dear PG developers, young and/or middle age, and rest users, please
check the errors the PG gave me.
happen as Adrian wrote, and life goes on.
What I would like to ask from developers is
Hi, I had a wonderful Sunday, and have no intention to change that sense!
Dear PG developers, young and/or middle age, and rest users, please
check the errors the PG gave me.
- 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 NU
## GPT (gptmailingli...@gmail.com):
> Why this incident has been observed when the statement is only within
> a function with variable as input parameter and not when they run
> directly with explicitly defined parameter/ In the first case, plan
> remains stable and does not change; but in the sec
## GPT (gptmailingli...@gmail.com):
> > And the important thing is: there is no guarantee that the same SQL
> > statement will always execute with the same plan:
> + Yes but there should be guarantee that when the statement is free of
> any syntactic error to be executed successfully and return th
On 10/27/18 8:00 AM, GPT wrote:
On 10/27/18, Adrian Klaver wrote:
On 10/27/18 2:28 AM, GPT wrote:
...
Postgres is going to do all sorts of things under the hood when you run
a query, that is not going to change.
+ Ok. That's clear.
+
The issue you had bubbled up to
you the user because the FD
On 10/27/18, Adrian Klaver wrote:
> On 10/27/18 2:28 AM, GPT wrote:
> ...
> Postgres is going to do all sorts of things under the hood when you run
> a query, that is not going to change.
+ Ok. That's clear.
+
> The issue you had bubbled up to
> you the user because the FDW you where using got cau
On 10/27/18 3:57 AM, GPT wrote:
And one more question:
Anyway, this is too technical for me and even if you respond most
probably I am not gonna get it.
Then why ask the question?
Tia
--
Adrian Klaver
adrian.kla...@aklaver.com
On 10/27/18 2:28 AM, GPT wrote:
On 10/26/18, Christoph Moench-Tegeder wrote:
## GPT (gptmailingli...@gmail.com):
...
And the important thing is: there is no guarantee that the same SQL
statement will always execute with the same plan:
+ Yes but there should be guarantee that when the stateme
And one more question:
Why this incident has been observed when the statement is only within
a function with variable as input parameter and not when they run
directly with explicitly defined parameter/ In the first case, plan
remains stable and does not change; but in the second case plan
changes
On 10/26/18, Christoph Moench-Tegeder wrote:
> ## GPT (gptmailingli...@gmail.com):
>
>...
>
> And the important thing is: there is no guarantee that the same SQL
> statement will always execute with the same plan:
+ Yes but there should be guarantee that when the statement is free of
any syntactic
## GPT (gptmailingli...@gmail.com):
> I have searched in
> https://github.com/nahanni/rw_redis_fdw/blob/master/redis_fdw.c for
> PREPARE and EXECUTE keywords. There are not any of them, except in
> comments.
Of course not - the FDW does not execute SQL on the PostgreSQL side,
but sends commands t
I have searched in
https://github.com/nahanni/rw_redis_fdw/blob/master/redis_fdw.c for
PREPARE and EXECUTE keywords. There are not any of them, except in
comments.
So, the developer doesn´t use any PREPARE, EXECUTE statements.
So, this change occurs internally. If I am correct then the PG fails
t
## GPT (gptmailingli...@gmail.com):
> So, this kind of switch after a few goes is a normal behavior or
> something unexpected which will change in future?
It's expected, and even documented (when you look at the user-level
interface):
https://www.postgresql.org/docs/current/static/sql-prepare.htm
So, this kind of switch after a few goes is a normal behavior or
something unexpected which will change in future?
I am asking in order to have my mind on incidents with similar behavior.
Tia
On 10/25/18, Andres Freund wrote:
> Hi,
>
> On 2018-10-25 11:43:39 +0200, GPT wrote:
>> I have faced a
Hi,
On 2018-10-25 11:43:39 +0200, GPT wrote:
> I have faced an incident which, according to the developer, "The
> problem seems to be that pgsql switches from a CONST sub-expression
> into a FUNCEXPR after a few goes, ..."
>
> Please have a look at the following two links which describe the probl
Hi,
I have faced an incident which, according to the developer, "The
problem seems to be that pgsql switches from a CONST sub-expression
into a FUNCEXPR after a few goes, ..."
Please have a look at the following two links which describe the problem:
https://github.com/nahanni/rw_redis_fdw/issues
25 matches
Mail list logo
