Unfortunately, only system and catalog properties can be overridden this way, but OpenLineage is neither of that - it's an EventListener with static configuration.

Also, using some query context fields as a new default for job name could lead to new issues:

• X-Trino-ClientInfo is an arbitrary string there some clients pass internal data. For example, Airflow TrinoHook passes a JSON value here with some Airflow DAG+Task Info. In contrast, OpenLineage job names should be the same for every run of the same script/query.
• X-Trino-Source sounds like a more suitable alternative, but it has default value provided by integration - trino-cli, trino-python-client, trino-jdbc, airflow, etc. So this static value will be bound to queries triggered by different users, which can produce a total mess in the lineage graph.

In #25704 I've implemented an different approach - configurable job name with several substitutions (queryId, source, user, principal). So Trino admins may configure OpenLineage integration depending on how Trino is used in their company/environment:

• If users have to pass distinct X-Trino-Source: My Awesome session for logical set of queries (e.g. produced by the same ETL script/task), they can use ${source}.
• If source of query doesn't matter, but only user does, they could use ${user} or ${source}-${user} instead.
• Default value is still ${queryId}, in case if someone relies on current behavior of integration.

This doesn't sound ideal for me, but it can solve this particular issue. Maybe some other source of job name should be used instead - I'm new to Trino, and may not know something yet.

@dolfinus Thanks for raising this. Having timestamp based query id as a job name seems more like a bug to me. Being able to configure would mitigate the issue.