UPDATE/DELETE with both an or=filter and a RETURNINGselect raises 42703 "column does not exist" for the filtered column

[slamadingdong]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

PostgREST returns 42703 column "<table>.<column>" does not exist for a column that does exist, on an UPDATE/DELETE that combines two features on the same request:

1. an or=(...) filter, and
2. a RETURNING projection (select= / Prefer: return=representation).

Either feature alone works. Only the combination fails. The column is fully present in Postgres (information_schema confirms it on public.user_companies, a single BASE TABLE) and is readable, writable, and grant-complete for the request role.

This breaks @supabase/supabase-js for the common .update(...).or(...).select(...) pattern, which emits exactly that combination.

To Reproduce

public.user_companies has columns check_employee_id, check_contractor_id, pay_schedule_id. Role service_role has SELECT/INSERT/UPDATE on all (verified via information_schema.role_column_grants). or parens/commas are URL-encoded; a never-matching id guard keeps every write a no-op, so each probe returns [] (or 204) when correct, isolating the error.

1. Write, no or, no select → OK

   curl -s -X PATCH "$URL/rest/v1/user_companies?id=eq.00000000-0000-0000-0000-000000000000" \
     -H "apikey: $KEY" -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
     -d '{"pay_schedule_id": null}'
   # => (204, no body)
   

2. Write, no or, WITH select → OK

   curl -s -X PATCH "$URL/rest/v1/user_companies?id=eq.00000000-0000-0000-0000-000000000000&select=id" \
     -H "apikey: $KEY" -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
     -H "Prefer: return=representation" -d '{"pay_schedule_id": null}'
   # => []
   

3. Write, WITH or, no select → OK

   curl -s -X PATCH "$URL/rest/v1/user_companies?id=eq.00000000-0000-0000-0000-000000000000&or=%28check_employee_id.not.is.null%2Ccheck_contractor_id.not.is.null%29" \
     -H "apikey: $KEY" -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
     -d '{"pay_schedule_id": null}'
   # => (204, no body)
   

4. Write, WITH or AND select → FAIL

   curl -s -X PATCH "$URL/rest/v1/user_companies?id=eq.00000000-0000-0000-0000-000000000000&or=%28check_employee_id.not.is.null%2Ccheck_contractor_id.not.is.null%29&select=id" \
     -H "apikey: $KEY" -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
     -H "Prefer: return=representation" -d '{"pay_schedule_id": null}'
   # => {"code":"42703","details":null,"hint":null,
   #     "message":"column user_companies.check_employee_id does not exist"}
   

Summary of the 2×2:

step	or=	select=	result
1	no	no	OK
2	no	yes	OK
3	yes	no	OK
4	yes	yes	42703

A pure read with the same or= filter (GET ...?select=id&or=(...)) also succeeds — the failure is specific to a mutation that has both or and a RETURNING projection.

The equivalent in supabase-js fails the same way, because .update(...).or(...).select(...) emits both:

await supabase
  .from('user_companies')
  .update({ pay_schedule_id: null })
  .or('check_employee_id.not.is.null,check_contractor_id.not.is.null')
  .select('id');
// => { code: '42703', message: 'column user_companies.check_employee_id does not exist' }

Expected behavior

An UPDATE/DELETE combining an or= filter with a RETURNING select should resolve columns identically to either feature used alone. A column resolvable in steps 2 and 3 must remain resolvable in step 4.

Screenshots

N/A — curl output is inline above.

System information

• OS: Linux (WSL2, Ubuntu) — server-side Node script
• Browser (if applies): N/A
• Version of supabase-js: 2.99.2
• Version of Node.js: 20.20.0
• Hosted Supabase project (Data API / PostgREST)

Additional context

Suspected cause. The qualified error ("user_companies.check_employee_id does not exist") on a table that otherwise resolves suggests the generated mutation SQL aliases the target relation for the RETURNING/CTE wrapper but emits the or-group predicate qualified by the original table name (user_companies.<col>) rather than the alias — making the reference a dangling correlation name, which Postgres reports as 42703 rather than a privilege or cache error. (Hypothesis — generated SQL not directly observable.)

Ruled out:

• Not Content-Profile / Accept-Profile. An earlier suspicion that the Content-Profile: public header was the trigger was an uncontrolled comparison. With or+select held constant, the header makes no difference.
• Not a stale schema cache. A column added in the same migration batch (pay_schedule_id) resolves fine on this table (no PGRST204 on the payload), so the cache is current. NOTIFY pgrst, 'reload schema' and a COMMENT ON TABLE DDL-triggered reload did not change the behavior.
• Not privileges. service_role has SELECT/INSERT/UPDATE on every column referenced (information_schema.role_column_grants).
• Not the API key format. Reproduces with both the legacy service_role JWT and the new sb_secret_ key (both map to service_role).

Workaround. Split the mutation so or and select never share a request: read matching ids with the or filter, then update by id=in.(...).

const { data: rows } = await supabase
  .from('user_companies').select('id')
  .or('check_employee_id.not.is.null,check_contractor_id.not.is.null');
await supabase

.from('user_companies').update({ pay_schedule_id })

.in('id', rows.map(r => r.id));

[kedar49]

I investigated this against the current Supabase/PostgREST stack, and this appears to already be fixed in newer PostgREST versions.

The issue reproduces on older PostgREST versions where UPDATE / DELETE requests combining both:

or=(...)
select=...
Prefer: return=representation

can fail with:

{
  "code": "42703",
  "message": "column <table>.<column> does not exist"
}

The likely root cause was in the mutation SQL generation path for representation-returning writes. When PostgREST builds an UPDATE or DELETE with a returned representation, it aliases/wraps the mutation target for the RETURNING projection. Older versions did not correctly scope logical filters like or= / and= inside that mutation-returning path, so the generated predicate could reference the original relation name instead of the alias currently valid in that SQL scope. PostgreSQL then reports 42703, even though the physical column exists.

I verified the behavior locally with a minimal repro table:

CREATE TABLE IF NOT EXISTS public.test_bug_42703 (
  id uuid DEFAULT gen_random_uuid() PRIMARY KEY,
  col1 text,
  col2 text,
  val integer
);

TRUNCATE TABLE public.test_bug_42703;

INSERT INTO public.test_bug_42703 (col1, col2, val)
VALUES
  ('a', null, 1),
  (null, 'b', 2);

Then tested the failing shape:

curl -i -X PATCH "http://127.0.0.1:54321/rest/v1/test_bug_42703?or=(col1.not.is.null,col2.not.is.null)&select=id" \
  -H "apikey: <anon-key>" \
  -H "Authorization: Bearer <anon-key>" \
  -H "Content-Type: application/json" \
  -H "Prefer: return=representation" \
  -d '{"val": 20}'

On the current local Supabase stack, this returns 200 OK with the expected representation payload. I also verified DELETE with the same or= + select= shape, and that works as well.

The relevant fix appears to be included in PostgREST v14.4+. In this repo, the self-hosted compose config currently points to:

postgrest/postgrest:v14.12

which is already patched. The current local CLI stack I tested is running PostgREST v14.5, which also includes the fix.

So the resolution should be to ensure the affected hosted/self-hosted environment is running PostgREST v14.4 or newer. For local Supabase CLI usage, updating the CLI to a version that pulls PostgREST v14.4+ should resolve the issue.

Suggested regression coverage:

1. PATCH with or= + select=id
2. DELETE with or= + select=id
3. PATCH / DELETE with or=(col.eq.value,other_col.eq.value)
4. PATCH / DELETE with or=(col.not.is.null,other_col.not.is.null)
5. Same requests with Prefer: return=representation
6. Same requests with select=* and multiple selected columns

Given the verification above, I don’t think this needs a Supabase-side code change if the deployed PostgREST version is already v14.4+. The main action is confirming the PostgREST version used by the affected project/environment.

[harrysun2006]

Nice isolation work — "either feature alone is fine, only the combination breaks" is a strong signal this is a genuine PostgREST bug rather than a grants/schema issue, and your information_schema checks back that up.

What's happening under the hood: on a mutation with return=representation, PostgREST wraps the write in a CTE and then projects the select= columns from it. The or=(...) filter's column reference ends up being resolved against that returning projection/CTE scope rather than the base table, so a column that exists on the table reads as "does not exist" (42703). A plain eq filter doesn't trip it because of how the simpler predicate is planned; the or group is what lands in the wrong scope.

Workarounds until it's fixed upstream:

• Split the call: do the .update(...).or(...) without .select(), then issue a separate .select() for the affected rows. Two round-trips, but it sidesteps the bad combination.
• Reshape the filter: if your or is expressible as an in.(...) or a single predicate, that avoids the or group entirely.
• Push it into an RPC: a small plpgsql/sql function that does the UPDATE ... RETURNING gives you the atomic write + representation without going through PostgREST's filter+returning combination.

Since this is reproducible and well-scoped, it's worth filing on the PostgREST repo (PostgREST/postgrest) with your minimal curl repro — it'll get triaged faster there than in Discussions. If you can include the PostgREST version (Dashboard → Project Settings → Infrastructure, or the Server header on a REST response) that'll help them pin the affected range.