support bigint parameters

[wmertens]

Description

When doing rpc calls with number parameters, bigint values need to be stringified, so you'd write {amount: bigintAmount.toString()}.

This is unintuitive, and the types also don't allow this.

Suggested solution

Do the JSON.stringify with a visitor that converts bigint to string, and change the generated type for number values to numbe | bigint

Alternative

keep the status quo

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[akbarfaa]

Hi, I’d like to work on a potential improvement regarding bigint support in RPC calls.

Before I proceed, a few clarifications:

• Are the affected types currently generated via OpenAPI?
• Should we implement a custom JSON replacer to handle bigint serialization?
• If the types need updating, should that be done directly in source, or via generator logic?

Once clarified, I can draft an implementation and tests.

Thanks!

[wmertens]

Hi,

• the types are generated in the https://github.com/supabase/postgres-meta project
• yes, just turn them into strings
• update the generator logic in a separate PR in https://github.com/supabase/postgres-meta

[akbarfaa]

Thanks for the clarification.

I’ve looked into the postgres-meta generator and found that the PostgreSQL → TypeScript mapping (pgTypeToTsType) is global.

Currently, int8 and numeric are mapped to number, and this mapping is reused for:

• Table/view row types
• Insert/Update types
• Function argument types
• Function return types

Changing int8 / numeric to string would therefore affect all generated types, not just RPC parameters.

Before proceeding, I’d like to confirm:

Should int8 / numeric be emitted as string everywhere (rows, inserts, updates, RPC args, and RPC return types)?

Or should this change be scoped to RPC input parameters only, which would require introducing a separate mapping path?

Happy to implement once scope is confirmed.

[wmertens]

No, the extra type should not be string, it should be bigint. And it should be added everywhere where it is appropriate, meaning not int8

[akbarfaa]

Hi,
I’ve updated the PR with bigint type support and the necessary fixes to make Docker tests pass consistently.
PR: supabase/postgres-meta#1044

This keeps int8 as number | bigint (additive/backward‑compatible) and preserves other numeric types.
Please let me know if anything else is needed.