You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While gixpp used with gix needs to have more information, gixsql doesn't; it seems reasonable to have a "mode" in the driver so additional checks and the full tree can be skipped depending on that.
The current implementation of with gixpp for gixsql (that normally don't includes any copybooks - and shouldn't), along with a code as follows
break the checks and lead to a "parser error" (which is actually not a parser error, but a syntax error and - #154 misses the location):
parse error: FILLER level should start from 01 or 66 or 77 or 88
If there's a "mode" applied in the driver then everything outside of EXEC SQL DECLARE can be skipped (= it doesn't matter if this is "partial" code like the one above, it doesn't matter which exotic USAGEs or TYPEDEFs are used - as long as the parser understands that).
At least in "gixsql mode" the field tree does not necessarily need to be built - or can at least silently ignoring "errors" (in the field case possibly add "implied" artificial fields with expected level as parent).
Note: currently there's a follow-up issue after this message as it leaves the driver without a current field, workaround for that sigsegv in #152.
While gixpp used with gix needs to have more information, gixsql doesn't; it seems reasonable to have a "mode" in the driver so additional checks and the full tree can be skipped depending on that.
The current implementation of with gixpp for gixsql (that normally don't includes any copybooks - and shouldn't), along with a code as follows
break the checks and lead to a "parser error" (which is actually not a parser error, but a syntax error and - #154 misses the location):
If there's a "mode" applied in the driver then everything outside of
EXEC SQL DECLARE
can be skipped (= it doesn't matter if this is "partial" code like the one above, it doesn't matter which exoticUSAGE
s orTYPEDEF
s are used - as long as the parser understands that).At least in "gixsql mode" the field tree does not necessarily need to be built - or can at least silently ignoring "errors" (in the field case possibly add "implied" artificial fields with expected level as parent).
Note: currently there's a follow-up issue after this message as it leaves the driver without a current field, workaround for that sigsegv in #152.
Workaround:
The text was updated successfully, but these errors were encountered: