plusplusjiajia opened a new pull request, #758:
URL: https://github.com/apache/paimon-rust/pull/758
### Purpose
A `query-auth.enabled` table makes the server return a per-user row filter
and column masking that a client is expected to apply. This client cannot apply
them yet, so it refuses to read such a table at all —
even for a user the server reports as unrestricted. This first slice
fetches the authorization at scan-plan time and carries it to the read, so that
user can read. A user with rules gets the same refusal as
before.
### Brief change log
`Table::authorize_read` asks the server once per plan, and
`TableScan::plan` stamps the result on every split — Java wraps each split in a
`QueryAuthSplit` for the same reason. `TableRead::to_arrow` then
decides from the splits: each must carry a grant, matching this table, and
unrestricted. Per split, not just the first, since split lists can be
concatenated across plans.
`QueryAuthGrant` keeps the response unparsed — parsing belongs with the
code that applies it — and the request names every column, ordinary and system
alike, since "nothing is restricted" is only sound if the server was asked
about everything. A user authorized for a subset is therefore still refused, as
today.
Two refusals are deliberate: a restricted grant fails at planning, since a
plan carries row counts and min/max that engines answer `COUNT`/`MIN`/`MAX`
from without reading a row; and a time-travelled or branch copy is refused,
since the server rules on the current schema. The `ReadBuilder::new_read` gate
is removed — it runs before any split exists — and the engine-served type check
it carried is restored at the plan and read boundaries.
--
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]
