Hi, colleges.
Found a server crash in PSQL which contains statement with **... RETURNING *** without INTO. It's an erroneous statement in PSQL without INTO, but it shouldn't terminate server.
Can be reproduced with such request:
set term !;
recreate table ttt (id int)!
execute block
as
begin
delete from ttt returning *;
end!
set term ;!
I'm going to make a PR and I want to discuss it. I'm not sure that my patch would be enough to fix this issue properly. After this fix instead of crash an error will be returned with zeroes in line and and column (like in FB4 on such request).
When we "explode" **RETURNING *** to multiple fields we have no line and column from parser due to NULL node from select_list parse.y rule.
It could be fixed if create kinda dummy node with line and column set, or provide host_statement argument to Jrd::dsqlProcessReturning() (FB5,FB6) or ReturningProcessor::explode() (FB4) with whole statement line and column, not just zeroes.
Appreciate your help.
Hi, colleges.
Found a server crash in PSQL which contains statement with **... RETURNING *** without INTO. It's an erroneous statement in PSQL without INTO, but it shouldn't terminate server.
Can be reproduced with such request:
I'm going to make a PR and I want to discuss it. I'm not sure that my patch would be enough to fix this issue properly. After this fix instead of crash an error will be returned with zeroes in line and and column (like in FB4 on such request).
When we "explode" **RETURNING *** to multiple fields we have no line and column from parser due to NULL node from select_list parse.y rule.
It could be fixed if create kinda dummy node with line and column set, or provide host_statement argument to
Jrd::dsqlProcessReturning()(FB5,FB6) orReturningProcessor::explode()(FB4) with whole statement line and column, not just zeroes.Appreciate your help.