Declared Local Temporary Tables in PSQL#9058
Conversation
|
Is infinite execution correct by design? execute block returns (n integer)
as
declare local temporary table t (
id integer not null
);
begin
insert into t(id)
values(1);
insert into t(id)
select id from t;
select count(*) from t into n;
suspend;
end! |
No, current local table blr (as used for RETURNING) is fragile. |
|
Please add documentation about declared ltt restrictions, specifically the number of LTTs per operator. Could you add the ability to declare indexes for such tables? |
I'm working on it. Will be added in another PR. |
|
|
||
| const Format* format = rpb->rpb_relation->currentFormat(tdbb); | ||
| Record* record = VIO_record(tdbb, rpb, format, tdbb->getDefaultPool()); | ||
| const Format* format = relation ? rpb->rpb_relation->currentFormat(tdbb) : localTable->format.getObject(); |
There was a problem hiding this comment.
Please explain why relation may be missing here (and other similar methods)? This seems to seriously complicate the logic.
There was a problem hiding this comment.
Multi-row RETURNING uses an old implementation of "local table" based in RecordBuffer.
There was a problem hiding this comment.
But multi-row RETURNING was introduced before this PR and rpb_relation was mandatory. Also, how can we INSERT/UPDATE/DELETE with a result set generated by RETURNING? I seem to miss something here.
There was a problem hiding this comment.
But multi-row
RETURNINGwas introduced before this PR andrpb_relationwas mandatory. Also, how can weINSERT/UPDATE/DELETEwith a result set generated byRETURNING? I seem to miss something here.
The old RecordBuffer implementation (blr_local_table_id) should be faster for its purpose, i.e., it does not need record visibility logic, so it continue to be used for multi-row RETURNING. And it did not used "relations".
|
@dyemanov do you have any more things before this can be merged? |
4 participants
No description provided.