Requesting non-existent item property causes performance degradation instead of an error

[drnextgis]

I use stac-fastapi in conjunction with a PgSTAC backend. Today, I noticed a troublesome issue: when a client sends a request to the /search endpoint (with the filter extension activated) using a non-existent Item property, the backend initiates a comprehensive scan to locate the item. This significantly impairs the database's performance. Is there a way to specify which properties are eligible for filtering, thus preventing unnecessary requests from being forwarded to the database? Alternatively, can this be configured on the PgSTAC side in some way?

[gadomski]

Is there a way to specify which properties are eligible for filtering

Yes, queryables. Try hitting /queryables or /collections/{id}/queryables.

can this be configured on the PgSTAC side in some way

I don't know the answer to this ... what would you want pgstac to do in the case where someone requets a non-existent property?

[drnextgis]

Thank you for the prompt reply! Please correct me if I'm wrong, but the "queriables" mechanism simply advertises properties that can be queried and doesn't serve to restrict queries for non-existent properties.

[gadomski]

doesn't serve to restrict queries for non-existent properties.

From the extension:

By default, the queryables are the only terms that may be used in filter expressions, and if any term is used in expression that is not defined as a queryable and (sic) error must be returned according to OAFeat Part 3.

So, unless additionalProperties is true, the server should be producing an error if any non-queryable is used in a filter. I don't believe stac-fastapi-pgstac is setting additionalProperties, so your original report is close to correct -- instead of a performance degradation, we should be returning an error. I'll update the title of this issue to reflect that, and thanks for the report.

[drnextgis]

I discovered today that there is a related ticket in the PgSTAC repository, indicating that this would be the appropriate place to implement this functionality.

[gadomski]

I'm going to transfer this issue to the stac-fastapi-pgstac repo as it's specific to pgstac (thought it might exist in *-sqlalchemy as well 🤷🏼.

[drnextgis]

Strict mode for search has been implemented in stac-utils/pgstac#216