Gateway Structured Select
Canonical nested select payloads for PostgreSQL-backed `/gateway/fetch`.
POST /gateway/fetch and POST /gateway/data now accept an additive
structured-select body for PostgreSQL-backed Athena clients and direct
x-pg-uri requests.
This does not replace the legacy columns + conditions contract. Both
shapes remain valid.
Supported request shapes
Athena accepts two structured-select inputs:
- Canonical nested
selectobjects - Compatibility
selectstrings
Canonical object payload
{
"table_name": "orchestral_sections",
"select": {
"name": true,
"instruments": {
"select": {
"name": true
},
"where": {
"active": {
"eq": true
}
},
"orderBy": {
"name": "asc"
},
"limit": 10
}
},
"where": {
"name": {
"neq": "brass"
}
},
"orderBy": {
"name": "asc"
},
"limit": 100
}Response shape is unchanged:
{
"status": "success",
"message": "Fetched 2 rows",
"data": [
{
"name": "strings",
"instruments": [
{
"name": "violin"
}
]
},
{
"name": "woodwinds",
"instruments": [
{
"name": "flute"
}
]
}
],
"cache_key": "..."
}Compatibility select string
Use this for migration from PostgREST/Supabase-style callers:
{
"table_name": "orchestral_sections",
"select": "name,instruments(name)",
"where": {
"instruments.name": {
"eq": "flute"
}
}
}String select is compatibility sugar. The object form is the canonical Athena
contract.
Cross-schema compatibility select string
{
"table_name": "public.chat_subscriptions",
"select": "user_id,users:athena.users(id,username,image)",
"where_filters": [
{
"column": "user_id",
"operator": "eq",
"value": "ef7a4c74-cc35-4d32-945a-a5271279ecdb",
"column_cast": "text"
}
],
"orderBy": [
{
"column": "user_id",
"direction": "desc"
}
],
"limit": 1
}This is the server-supported cross-schema relation grammar for Athena 2.4.0
compatibility work:
- schema-qualified base tables such as
public.chat_subscriptions - relation-side schema qualification such as
users:athena.users(id,username,image)
Validation failures use the normalized gateway envelope:
{
"status": "error",
"message": "Invalid relation-select compatibility query",
"error": "table 'athena.user' was not found for structured gateway fetch",
"code": "VALIDATION_FAILED",
"data": {
"operation": "fetch"
}
}Query semantics
- Root and relation filters support
eq,neq,gt,lt, andin. - Relation-level
where,orderBy,limit, andoffsetare supported. - Canonical relation projections default to left-join semantics.
- Compatibility select strings support
!innerwhen parent-row filtering is required. - Nested collection
!innerfilters parent rows when the child collection is empty. - Relation joins resolve from database foreign-key metadata first, then from a
verified
*_idfallback. If Athena cannot resolve the edge safely, provideforeign_key. - When API-key enforcement is enabled, Athena checks read rights for every referenced table in the structured tree, not just the root table.
schema_namestill works for PostgreSQL-backed requests whentable_nameis not already schema-qualified.
Current scope
- Structured select is supported on PostgreSQL-backed gateway fetch execution.
- Legacy
columnspayloads remain the right choice for wildcard fetches. - Nested wildcard projection (
*inside structured relation/object select) is not supported. - Bare
where/orderBykeys do not opt into structured select. Athena only treats the body as structured whenselectis present. - Non-PostgreSQL gateway fetch backends keep the legacy
columns/conditionscontract. - First-class direct AST request bodies (
operation/from/fields) are not part of the current public/gateway/fetchcontract. - Relation
onshapes and schema-qualified relation selectors combined withviaare not supported in this release and return400 VALIDATION_FAILED.
See Gateway API for the full route overview and
Direct PostgreSQL Routing (x-pg-uri)
for auth/routing behavior.