# Filter an ordinary view with query parameters

Use an ordinary view for the reusable portion of a query and place caller-specific predicates in the SELECT that reads it. A view definition does not declare invocation arguments.

```sql
CREATE TABLE customer_orders(id INTEGER PRIMARY KEY, account_id INTEGER, amount INTEGER);
CREATE VIEW positive_orders AS
SELECT id, account_id, amount
FROM customer_orders
WHERE amount > 0;

SELECT id, amount
FROM positive_orders
WHERE account_id = 42
ORDER BY id;
```

The application supplies the account value for its own request. With the embedded connection API, prepared statements provide binding for values. Do not construct SQL by concatenating untrusted input. HTTP SQL requests do not accept bound parameters, so their caller must use a correctly escaped SQL value or another suitable application interface.

This filter is query behavior, not an access policy. A user allowed to submit arbitrary SQL is not restricted to the filtered view; database roles and row-level permissions are unavailable. Enforce any account boundary in the application and deployment that controls access.

See [`CREATE VIEW`](https://coordinatordb.com/docs/reference/statements/create/view), [prepared statements](https://coordinatordb.com/docs/guides/clickhouse/data-modelling/stored-procedures-and-prepared-statements) and [authentication](https://coordinatordb.com/docs/concepts/features/security).