ClaireLytt commented on PR #38733:
URL: https://github.com/apache/shardingsphere/pull/38733#issuecomment-4608869668
@terrymanu
Thank you for your review sugestion.
There are 4 changes in my new commit.
* Scope target-alias binding to SQL Server in
`shardingsphere\infra\binder\core\src\main\java\org\apache\shardingsphere\infra\binder\engine\segment\dml\from\type\SimpleTableSegmentBinder.java`
and
`shardingsphere\infra\binder\core\src\main\java\org\apache\shardingsphere\infra\binder\engine\statement\dml\UpdateStatementBinder.java`
* a non-target dialect counterexample. PostgreSQL/openGauss should not
silently treat UPDATE alias SET ... FROM actual_table AS alias ... as a valid
alias-target update grammar.
I have added a valid case for PostgreSQL/openGauss in
`test/it/rewriter/src/test/resources/scenario/encrypt/case/query-with-cipher/dml/update/update.xml`
and there are screenshots when I run the same statement for SqlServer
but db-types in PostgreSQL/openGauss,they failed
* Fix `The target alias is still exposed as a table name to downstream
routing/rewrite consumers`
in
`parser/sql/statement/core/src/main/java/org/apache/shardingsphere/sql/parser/statement/core/extractor/TableExtractor.java`
* Add a regression test that asserts
`UpdateStatementContext.getTablesContext().getTableNames()` contains the real
target/source tables and does not expose `sr` as a table.
in
`infra/binder/core/src/test/java/org/apache/shardingsphere/infra/binder/context/statement/type/dml/UpdateStatementContextTest.java`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
