PostgREST 14.5 Nested INSERT Fails With PGRST204 Unless `?Select=*,<Child>(*)` Is Supplied

PostgREST 14.5 builds the RETURNING projection for an embedded insert from top-level payload keys when no `select` parameter is present. Each key is passed to `lookupColumn` on the parent table before relationship resolution, so a valid FK relationship name such as `child_probe` raises `PGRST204` as if it were an unknown column. The read-embed path uses the query parser and therefore resolves the same FK correctly.

Create two tables with a validated FK: ```sql create table parent_probe (id uuid primary key default gen_random_uuid(), name text not null); create table child_probe ( id uuid primary key default gen_random_uuid(), parent_id uuid not null references parent_probe(id) on delete cascade, name text not null ); ``` Authenticate with a JWT that can insert into both tables, then run: ```bash curl -X POST "$URL/rest/v1/parent_probe" \ -H "apikey: $PUBLISHABLE" -H "Authorization: Bearer $JWT" \ -H "Content-Type: application/json" -H "Prefer: return=representation" \ -d '{"name":"p","child_probe":[{"name":"c"}]}' ``` Result: 400 `{"code":"PGRST204","message":"Could not find the 'child_probe' column of 'parent_probe' in the schema cache"}`.

This is a client-side hotfix: every nested insert must remember to include the explicit `select` parameter. If omitted, the PGRST204 error returns intact. The `select=*,child_probe(*)` response can be larger because it includes child rows; if the client does not need the returned representation, use `Prefer: return=minimal` instead. If the server still errors after adding `select`, upgrade PostgREST to a version where the payload-inference bug is fixed, or fall back to a transactional RPC. Rollback: remove the `select` parameter or switch to `return=minimal`.