-
-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove context limit for stored procedures/functions/triggers as well as for user SQL queries [CORE809] #1195
Comments
Commented by: Alice F. Bird (firebirds) Date: 2006-01-25 13:29 Size limit for SPs/triggers and limit of available record |
Modified by: @pcisarissuetype: New Feature [ 2 ] => Improvement [ 4 ] assignee: Dmitry Yemanov [ dimitr ] SF_ID: 1412839 => |
Modified by: @pcisarassignee: Dmitry Yemanov [ dimitr ] => |
Modified by: @pcisarWorkflow: jira [ 10833 ] => Firebird [ 15269 ] |
Modified by: @dyemanovassignee: Dmitry Yemanov [ dimitr ] |
Modified by: @dyemanovdescription: SFID: 1412839# Have a look at the summary. If a stored procedure / Invalid token. Invalid request BLR at offset xxxx. Best wishes, Marc Geldon => SFID: 1412839# Have a look at the summary. If a stored procedure / trigger is too complex, you'll get the following error: Invalid token. Invalid request BLR at offset xxxx. Every table/procedure reference means a "context" and their total count is limited by 256 contexts. Removing or extending this limit would allow more complex PSQL code to be developed. summary: Remove limit for size of stored procedures / triggers => Remove context limit for stored procedures / triggers |
Modified by: @dyemanovFix Version: 4.0 Alpha 1 [ 10731 ] |
Commented by: @dyemanov No, v3.0 has the same limit of 256 contexts. However, it has some minor improvements, in particular it generates less contexts for N-way unions. |
Commented by: Volker Rehn (vr2_s18) This can close a gap and provide a method to bulk load within user/attachment/transaction contexts. A simple example would be an insert script within a dynamically generated and executed execute block. This does not have the restrictions of external tables. It won't be as fast as external tables, but those are just too restrictive in many cases. |
Modified by: @dyemanovFix Version: 4.0 Beta 1 [ 10750 ] => |
Why is there a limit for update/insert/delete, but I can set as many stored procedures as I want? |
The limit applies to the BLR (byte code) where every table reference is encoded with a single-byte number. Thus the limit is static and does not affect how many times the procedure is executed. |
And how is it possible to execute an unlimited number of stored procedures within an execute block? |
|
Is this really hard to have blr with 2, 3, 4 bytes context number instead of current one? Is Blr versioned? |
Thanks for reminder, I believe we should schedule this improvement for v6. This shouldn't be very hard, I've attempted it once. BLR is indeed versioned and we may just raise the BLR version number instead of duplicating all BLR verbs that contain stream number(s). But I'd prefer to use new BLR version only if the code really overflows the 255 limit. This would make the usual code backward compatible and down-gradable if required. |
Yes, backward compatibility is an important consideration. |
Submitted by: marcgeldon (marcgeldon)
Is duplicated by CORE2694
Votes: 12
SFID: 1412839#
Submitted By: marcgeldon
Have a look at the summary. If a stored procedure / trigger is too complex, you'll get the following error:
Invalid token. Invalid request BLR at offset xxxx.
"context not defined (BLR error)"
or
"Too many Contexts of Relation/Procedure/Views. Maximum allowed is 256"
Every table/procedure reference means a "context" and their total count is limited by 256 contexts. Removing or extending this limit would allow more complex PSQL code to be developed.
The text was updated successfully, but these errors were encountered: