eschutho commented on code in PR #43870:
URL: https://github.com/apache/superset/pull/43870#discussion_r4253803176
##########
superset/config.py:
##########
@@ -2553,6 +2585,24 @@ def engine_context_manager( # pylint:
disable=unused-argument
"getMacro",
"getSetting",
},
+ # Oracle functions that run a query handed to them as text. Same blind spot
+ # as PostgreSQL's XML and full-text families above: the statement they
+ # execute is a string, so the expression has no FROM clause and no
+ # sub-query of its own for a table-reference gate to see, and the rows come
+ # back without the dataset grants or row-level security the caller is
+ # subject to.
+ #
+ # Named bare rather than package-qualified: `DBMS_XMLGEN.GETXML(...)`
+ # parses as an anonymous function called `GETXML`, so the package prefix
+ # never reaches the matcher. `getclobval` and `extract` are deliberately
+ # absent -- they read an XMLType the caller already has rather than
+ # building one from a query.
+ "oracle": {
+ "getxml",
+ "getxmltype",
+ "newcontext",
+ "newcontextfromhierarchy",
Review Comment:
Replying on Hugh's behalf: Hugh fixed this in 571fc58493 (`fix(security):
deny the Oracle function that reads a table by path string`). `dburitype` is
now in the `oracle` set of `DISALLOWED_SQL_FUNCTIONS`, as you suggested, with a
comment explaining why. I checked it at the current head:
`stored_expression_error` rejects
`DBURITYPE('/HR/EMPLOYEES/ROW[ID=1]/SALARY').getclob() || :value` (in either
case) with "A partition value transform cannot call dburitype." and still
accepts `lower(:value)`.
##########
superset/db_engine_specs/postgres.py:
##########
@@ -178,6 +178,15 @@ class PostgresBaseEngineSpec(BaseEngineSpec):
engine = ""
engine_name = "PostgreSQL"
+ # The engine's default text comparison is binary, so a mirrored
+ # ``partition_col = T(v)`` agrees with the ``col = v`` it stands in for.
+ binary_string_comparison = True
+
+ # PostgreSQL's date/time input reads the unseparated forms as well as the
+ # ISO ones -- ``'20260115'::date`` is 2026-01-15 -- so a ``YYYYMMDD``
+ # bucketing key mirrors here. Redshift inherits the same input parsing.
+ temporal_literal_formats = ("%Y%m%d", "%Y%m%d%H%M%S")
Review Comment:
Replying on Hugh's behalf: Hugh fixed this in 15cc6a83fd (`fix(datasets):
let the engine say which text it reads as an instant`).
`temporal_literal_formats = POSTGRES_TEMPORAL_LITERAL_FORMATS` is now declared
on `PostgresEngineSpec` and `RedshiftEngineSpec` instead of the shared
`PostgresBaseEngineSpec`. Snowflake, Vertica, HANA, Netezza and Hologres
therefore fall back to the base `()` and decline the mirror rather than
emitting `part_date = '20260115'`. I checked the resolved values at the current
head. `test_a_postgres_relative_does_not_inherit_the_day_key` covers it.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
