Primary keys not working with GENERATED ALWAYS AS IDENTITY columns

[lauri865]

Describe the bug I'm using GENERATED ALWAYS AS IDENTITY primary key definitions, which is great, because it makes sure that no-one can accidentally update id columns. It's still possible manually, but needs to be an intentional behavior with OVERRIDING SYSTEM VALUE clause.

However, it doesn't seem to work with supabase-cache-helpers, since it requires primary keys to be part of the update payload to build filters, but doesn't remove them from it.

The resulting payload is:

curl 'https://local.test/rest/v1/companies?id=eq.212&select=name%2Cdescription%2Cid' \
  -X 'PATCH' \
  --data-raw '{"name":"Name","description":"description","id":212}' \

Which reults in the following error:

{
  "code": "428C9",
  "details": "Column \"id\" is an identity column defined as GENERATED ALWAYS.",
  "hint": null,
  "message": "column \"id\" can only be updated to DEFAULT"
}

I think it's a bad practice in general to include primary keys in the update payload by default. Foreign keys, sure, but there's little reasons to make primary keys mutable, and it's just a potential source of unintentional errors / breaking data integrity.

Related code: https://github.com/psteinroe/supabase-cache-helpers/blob/ec72756cf7dc202b16499cfd5b0cfd1bde779b85/packages/postgrest-core/src/update-fetcher.ts#L43

Suggested solution Remove primary_key values from the update payload by default, and enable it with e.g. opts.stripPrimaryKeysFromData = false or equivalent. It could be a breaking change though for some (even if unintentionally), so for a minor version, stripping primary keys could also be opt-in.