On Thu, Feb 22, 2018 at 1:27 PM, iPeel <dabs@peely.com> wrote:
I'm noticing that when executing a batch with multiple statements, the messages returned by the second statement onwards are kept over to the next execution and appear before the first message from the new batch.
Steps to reproduce:
Compile the following function which raises a notice:
create or replace function noticetest (vIn varchar) returns varchar as $$ begin raise notice 'You said %', vIn; return vIn; end $$ language plpgsql;
Then in a Query Tool window, execute the following statements in a single execution:
Observe the Messages pane, which displays the output:
NOTICE: You said One
Successfully run. Total query runtime: 91 msec. 1 rows affected.
Only the first message is shown in the window, the notice raised from the second statement is not shown. Now execute the following statement in the same execution:
Successfully run. Total query runtime: 75 msec. 1 rows affected.
The missing message from the first execution appears along with only the notice raised in the first statement of the second batch executed. Finally, execute a single statement:
The messages pane shows:
select noticetest('Five');
NOTICE: You said Four NOTICE: You said Five
Successfully run. Total query runtime: 67 msec. 1 rows affected.
Again the same behaviour as before. It seems that PgAdmin doesn't fully read the message array from each multi-statement execution, only the first but then somehow catches up prior to the next execution, falling behind again if there's multiple statements.
As the results window only shows the last result set, I use notices a fair bit for dba functions that are frequently executed in batch to keep track of the non-critical success state of individual operations. It'd be nice if I could see the outcome of notices raised without having to execute a second batch.
The workaround currently is to execute a separate statement after the main batch e.g.:
select '';
.. and observe the message output in that execution.