Extend the ability of planner_node_transformer_hook to store the context of expression being process #469
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ext of expression being process
66c2c58 to
6237170
Compare
1 task
KushaalShroff
approved these changes
Nov 19, 2024
de7d33c
into
babelfish-for-postgresql:BABEL_4_X_DEV__PG_16_X
2 checks passed
Deepesh125
added a commit
to babelfish-for-postgresql/babelfish_extensions
that referenced
this pull request
Nov 19, 2024
…rgetList) (#3011) Currently, declared local variables are assumed to be static by analyser and hence it is replaced with const node by optimiser. Currently, the parameter value will be supplied through pltsql_param_fetch(..) which is setup during pltsql_estate_setup as part of ParamListInfo setup. This hook is purely used during planning phase and is not used during query execution. If parameter value is required during execution then values will be read from estate->ndatums through pltsql_param_eval_var callback for EEOP_PARAM_CALLBACK step. This estate->ndatums setup during pltsql_estate_setup and values are copied through copy_pltsql_datums(…). And currently, any assignments to declare variables are implemented using "select target" which will be executed at the end of executor. Hence, any use of variables will read original (value copied during pltsql_estate_setup(...)) and it would not reflect any dynamic change in the value of any variable. In order to make this behaviour dynamic, this commit introduces internal function sys.pltsql_assign_var(dno, expr). Argument dno is item number of declared variable and expr could be anything whose value will be assigned to declared variable pointed by dno during execution. We will use this function to rewrite any variables assignment operation during ANTLR parsing as stated in following example, select @A = expr Will be written to select @A = sys.pltsql_assign_var(dno, expr) Internally, sys.pltsql_assign_var invokes exec_assign_value(…) to assign appropriate value directly to variable by updating estate->ndatums array and hence any subsequent read will read latest value. Engine PR: babelfish-for-postgresql/postgresql_modified_for_babelfish#469 Task: BABEL-5325 Signed-off-by: Dipesh Dhameliya <dddhamel@amazon.com>
roshan0708
pushed a commit
to amazon-aurora/postgresql_modified_for_babelfish
that referenced
this pull request
Nov 20, 2024
…ext of expression being processed (babelfish-for-postgresql#469) Extend the ability of planner_node_transformer_hook to store the context of expression being process. This saved context will be used during planning to transform declared variable either as a Param (if it appears in TargetList) or as a const (all the other places). Extension: babelfish-for-postgresql/babelfish_extensions#3011 Task: BABEL-5188 Signed-off-by: Dipesh Dhameliya <dddhamel@amazon.com>
roshan0708
pushed a commit
to amazon-aurora/babelfish_extensions
that referenced
this pull request
Nov 20, 2024
…rgetList) (babelfish-for-postgresql#3011) Currently, declared local variables are assumed to be static by analyser and hence it is replaced with const node by optimiser. Currently, the parameter value will be supplied through pltsql_param_fetch(..) which is setup during pltsql_estate_setup as part of ParamListInfo setup. This hook is purely used during planning phase and is not used during query execution. If parameter value is required during execution then values will be read from estate->ndatums through pltsql_param_eval_var callback for EEOP_PARAM_CALLBACK step. This estate->ndatums setup during pltsql_estate_setup and values are copied through copy_pltsql_datums(…). And currently, any assignments to declare variables are implemented using "select target" which will be executed at the end of executor. Hence, any use of variables will read original (value copied during pltsql_estate_setup(...)) and it would not reflect any dynamic change in the value of any variable. In order to make this behaviour dynamic, this commit introduces internal function sys.pltsql_assign_var(dno, expr). Argument dno is item number of declared variable and expr could be anything whose value will be assigned to declared variable pointed by dno during execution. We will use this function to rewrite any variables assignment operation during ANTLR parsing as stated in following example, select @A = expr Will be written to select @A = sys.pltsql_assign_var(dno, expr) Internally, sys.pltsql_assign_var invokes exec_assign_value(…) to assign appropriate value directly to variable by updating estate->ndatums array and hence any subsequent read will read latest value. Engine PR: babelfish-for-postgresql/postgresql_modified_for_babelfish#469 Task: BABEL-5325 Signed-off-by: Dipesh Dhameliya <dddhamel@amazon.com>
roshan0708
pushed a commit
to amazon-aurora/babelfish_extensions
that referenced
this pull request
Nov 20, 2024
…rgetList) (babelfish-for-postgresql#3011) Currently, declared local variables are assumed to be static by analyser and hence it is replaced with const node by optimiser. Currently, the parameter value will be supplied through pltsql_param_fetch(..) which is setup during pltsql_estate_setup as part of ParamListInfo setup. This hook is purely used during planning phase and is not used during query execution. If parameter value is required during execution then values will be read from estate->ndatums through pltsql_param_eval_var callback for EEOP_PARAM_CALLBACK step. This estate->ndatums setup during pltsql_estate_setup and values are copied through copy_pltsql_datums(…). And currently, any assignments to declare variables are implemented using "select target" which will be executed at the end of executor. Hence, any use of variables will read original (value copied during pltsql_estate_setup(...)) and it would not reflect any dynamic change in the value of any variable. In order to make this behaviour dynamic, this commit introduces internal function sys.pltsql_assign_var(dno, expr). Argument dno is item number of declared variable and expr could be anything whose value will be assigned to declared variable pointed by dno during execution. We will use this function to rewrite any variables assignment operation during ANTLR parsing as stated in following example, select @A = expr Will be written to select @A = sys.pltsql_assign_var(dno, expr) Internally, sys.pltsql_assign_var invokes exec_assign_value(…) to assign appropriate value directly to variable by updating estate->ndatums array and hence any subsequent read will read latest value. Engine PR: babelfish-for-postgresql/postgresql_modified_for_babelfish#469 Task: BABEL-5325 Signed-off-by: Dipesh Dhameliya <dddhamel@amazon.com>
Deepesh125
added a commit
to amazon-aurora/babelfish_extensions
that referenced
this pull request
Nov 21, 2024
…rgetList) (babelfish-for-postgresql#3011) Currently, declared local variables are assumed to be static by analyser and hence it is replaced with const node by optimiser. Currently, the parameter value will be supplied through pltsql_param_fetch(..) which is setup during pltsql_estate_setup as part of ParamListInfo setup. This hook is purely used during planning phase and is not used during query execution. If parameter value is required during execution then values will be read from estate->ndatums through pltsql_param_eval_var callback for EEOP_PARAM_CALLBACK step. This estate->ndatums setup during pltsql_estate_setup and values are copied through copy_pltsql_datums(…). And currently, any assignments to declare variables are implemented using "select target" which will be executed at the end of executor. Hence, any use of variables will read original (value copied during pltsql_estate_setup(...)) and it would not reflect any dynamic change in the value of any variable. In order to make this behaviour dynamic, this commit introduces internal function sys.pltsql_assign_var(dno, expr). Argument dno is item number of declared variable and expr could be anything whose value will be assigned to declared variable pointed by dno during execution. We will use this function to rewrite any variables assignment operation during ANTLR parsing as stated in following example, select @A = expr Will be written to select @A = sys.pltsql_assign_var(dno, expr) Internally, sys.pltsql_assign_var invokes exec_assign_value(…) to assign appropriate value directly to variable by updating estate->ndatums array and hence any subsequent read will read latest value. Engine PR: babelfish-for-postgresql/postgresql_modified_for_babelfish#469 Task: BABEL-5325 Signed-off-by: Dipesh Dhameliya <dddhamel@amazon.com>
1 task
rishabhtanwar29
pushed a commit
to amazon-aurora/postgresql_modified_for_babelfish
that referenced
this pull request
Nov 25, 2024
…ext of expression being processed (babelfish-for-postgresql#469) Extend the ability of planner_node_transformer_hook to store the context of expression being process. This saved context will be used during planning to transform declared variable either as a Param (if it appears in TargetList) or as a const (all the other places). Extension: babelfish-for-postgresql/babelfish_extensions#3011 Task: BABEL-5188 Signed-off-by: Dipesh Dhameliya <dddhamel@amazon.com>
rishabhtanwar29
pushed a commit
to amazon-aurora/babelfish_extensions
that referenced
this pull request
Nov 25, 2024
…rgetList) (babelfish-for-postgresql#3011) Currently, declared local variables are assumed to be static by analyser and hence it is replaced with const node by optimiser. Currently, the parameter value will be supplied through pltsql_param_fetch(..) which is setup during pltsql_estate_setup as part of ParamListInfo setup. This hook is purely used during planning phase and is not used during query execution. If parameter value is required during execution then values will be read from estate->ndatums through pltsql_param_eval_var callback for EEOP_PARAM_CALLBACK step. This estate->ndatums setup during pltsql_estate_setup and values are copied through copy_pltsql_datums(…). And currently, any assignments to declare variables are implemented using "select target" which will be executed at the end of executor. Hence, any use of variables will read original (value copied during pltsql_estate_setup(...)) and it would not reflect any dynamic change in the value of any variable. In order to make this behaviour dynamic, this commit introduces internal function sys.pltsql_assign_var(dno, expr). Argument dno is item number of declared variable and expr could be anything whose value will be assigned to declared variable pointed by dno during execution. We will use this function to rewrite any variables assignment operation during ANTLR parsing as stated in following example, select @A = expr Will be written to select @A = sys.pltsql_assign_var(dno, expr) Internally, sys.pltsql_assign_var invokes exec_assign_value(…) to assign appropriate value directly to variable by updating estate->ndatums array and hence any subsequent read will read latest value. Engine PR: babelfish-for-postgresql/postgresql_modified_for_babelfish#469 Task: BABEL-5325 Signed-off-by: Dipesh Dhameliya <dddhamel@amazon.com>
shardgupta
pushed a commit
that referenced
this pull request
Nov 25, 2024
…ext of expression being processed (#469) Extend the ability of planner_node_transformer_hook to store the context of expression being process. This saved context will be used during planning to transform declared variable either as a Param (if it appears in TargetList) or as a const (all the other places). Extension: babelfish-for-postgresql/babelfish_extensions#3011 Task: BABEL-5188 Signed-off-by: Dipesh Dhameliya <dddhamel@amazon.com>
shardgupta
pushed a commit
to babelfish-for-postgresql/babelfish_extensions
that referenced
this pull request
Nov 25, 2024
…rgetList) (#3011) Currently, declared local variables are assumed to be static by analyser and hence it is replaced with const node by optimiser. Currently, the parameter value will be supplied through pltsql_param_fetch(..) which is setup during pltsql_estate_setup as part of ParamListInfo setup. This hook is purely used during planning phase and is not used during query execution. If parameter value is required during execution then values will be read from estate->ndatums through pltsql_param_eval_var callback for EEOP_PARAM_CALLBACK step. This estate->ndatums setup during pltsql_estate_setup and values are copied through copy_pltsql_datums(…). And currently, any assignments to declare variables are implemented using "select target" which will be executed at the end of executor. Hence, any use of variables will read original (value copied during pltsql_estate_setup(...)) and it would not reflect any dynamic change in the value of any variable. In order to make this behaviour dynamic, this commit introduces internal function sys.pltsql_assign_var(dno, expr). Argument dno is item number of declared variable and expr could be anything whose value will be assigned to declared variable pointed by dno during execution. We will use this function to rewrite any variables assignment operation during ANTLR parsing as stated in following example, select @A = expr Will be written to select @A = sys.pltsql_assign_var(dno, expr) Internally, sys.pltsql_assign_var invokes exec_assign_value(…) to assign appropriate value directly to variable by updating estate->ndatums array and hence any subsequent read will read latest value. Engine PR: babelfish-for-postgresql/postgresql_modified_for_babelfish#469 Task: BABEL-5325 Signed-off-by: Dipesh Dhameliya <dddhamel@amazon.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…
Description
Extend the ability of planner_node_transformer_hook to store the context of expression being process. This saved context will be used during planning to transform declared variable either as a Param (if it appears in TargetList) or as a const (all the other places).
Issues Resolved
Extension: babelfish-for-postgresql/babelfish_extensions#3011
Task: BABEL-5188
Signed-off-by: Dipesh Dhameliya dddhamel@amazon.com
Check List
By submitting this pull request, I confirm that my contribution is under the terms of the PostgreSQL license, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.