pathwaycom/pathway · error · ValueError

designated_timestamp is passed, but designated_timestamp_pol

Error message

designated_timestamp is passed, but designated_timestamp_policy is {designated_timestamp_policy}

What it means

Raised by pw.io.questdb.write when a designated_timestamp column is supplied together with a designated_timestamp_policy that is neither None nor 'use_column'. The policy parameter only exists to make the implicit choice explicit; passing a different value while also giving a column is contradictory, so Pathway rejects the combination at configuration time.

Source

Thrown at python/pathway/io/questdb/__init__.py:142

    The command will prompt for a password. Unless you have changed it, the default password is
    ``quest``. Once connected, you can run:

    .. code-block:: sql

        qdb=> select * from test;

    And see the contents of the table.
    """
    _check_entitlements("questdb")

    designated_timestamp_index = None
    if designated_timestamp is not None:
        if (
            designated_timestamp_policy is not None
            and designated_timestamp_policy != "use_column"
        ):
            raise ValueError(
                f"designated_timestamp is passed, but designated_timestamp_policy is {designated_timestamp_policy}"
            )
        designated_timestamp_policy = "use_column"
        designated_timestamp_index = get_column_index(table, designated_timestamp)
        timestamp_dtype = table.schema.columns()[designated_timestamp.name].dtype
        if timestamp_dtype not in (dt.DATE_TIME_NAIVE, dt.DATE_TIME_UTC):
            raise ValueError(
                f"the designated_timestamp column {designated_timestamp.name!r} must have "
                f"type DateTimeNaive or DateTimeUtc, but it has type {timestamp_dtype}"
            )
    elif designated_timestamp_policy == "use_column":
        raise ValueError(
            'designated_timestamp_policy="use_column" requires the '
            "designated_timestamp parameter to be set"
        )
    elif designated_timestamp_policy is None:
        designated_timestamp_policy = "use_now"

View on GitHub (pinned to fa2f74a464)

Solutions

  1. Drop the designated_timestamp_policy argument entirely — when designated_timestamp is given, the policy defaults to use_column.
  2. Or set designated_timestamp_policy='use_column' explicitly to match the column you passed.
  3. If you wanted QuestDB's server-side now() as the designated timestamp, remove the designated_timestamp column argument instead.

Example fix

# before
pw.io.questdb.write(t, conn, "t", designated_timestamp=t.ts,
                    designated_timestamp_policy="use_now")

# after
pw.io.questdb.write(t, conn, "t", designated_timestamp=t.ts)
Defensive patterns

Strategy: validation

Validate before calling

pw.io.questdb.write(t, conn, "t", designated_timestamp=t.ts)  # policy omitted -> use_column

Prevention

When it happens

Trigger: pw.io.questdb.write(t, connection_string, 't', designated_timestamp=t.ts, designated_timestamp_policy='use_now') — any policy string other than 'use_column' (or omitting it) together with a designated_timestamp column.

Common situations: Copy-pasting a fully-populated kwargs block from another call site where the policy was set to use_now; config-driven writes that always pass every parameter; discovering the policy enum and setting it 'for completeness'.

Related errors


AI-assisted analysis of pathwaycom/pathway@fa2f74a464 (2026-08-15). Data as JSON: /api/errors/76f26fbe58123308. Report an issue: GitHub.