[tanjiroK-coder]

SelectValidator.visit(PlainSelect) never validated the select list: the call was commented out with a @todo about aliased tables, so nothing in it reached ExpressionValidator and no ValidationCapability saw it. DISTINCT ON, TOP, QUALIFY, named WINDOW definitions and the LIMIT / OFFSET / FETCH row counts were skipped the same way (LimitValidator and validateOffset only reported features, validateFetch only looked at a JDBC parameter). With FeaturesAllowed.SELECT.copy().remove(Feature.function), SELECT 1 FROM t WHERE pg_read_file('/etc/passwd') IS NOT NULL reports function not allowed. but SELECT pg_read_file('/etc/passwd') validates with no errors, and with FeaturesAllowed.SELECT a FOR UPDATE subquery is rejected in WHERE but accepted as SELECT (SELECT a FROM t FOR UPDATE). A few existing tests work around it by putting the expression in WHERE (testValidateFunctionArgumentInWhere, SqlServerXmlMethodTest.validatesMethodAsFunction).

The select list, DISTINCT ON and TOP are now validated right after the FROM items, so table aliases resolve as the old comment intended (testValidationMetadataSelectWithColumnsAndAlias2, select my.id from mytable as my, now really checks my.id and still passes), and the other clauses go through the same helpers as WHERE and ORDER BY. One visible effect for JdbcDatabaseMetaDataCapability users: select-list columns are now looked up like WHERE columns, so a column of a derived table (SELECT x.c FROM (SELECT ...) x) is reported there the way WHERE x.c = 1 already is. The new cases in SelectValidatorTest (11 clauses plus the FOR UPDATE subquery) and DatabaseMetaDataValidationTest fail before the change and pass after; ./gradlew check and mvn verify pass.