fix(typegen): Fix support for custom SQL schemas in TypeScript type generation.

[yingw787]

What kind of change does this PR introduce?

[x] Patches PR #654 to support SQL schemas outside of "public". Cannot directly use keyword "schema" due to circular type constraint error in definition PublicTableNameOrOptions.
[x] Update type generation tests to reflect updated TypeScript types, with local run of npm run test confirming 96 tests passed.

Addresses GitHub issue #716.

What is the current behavior?

When running:

PG_META_GENERATE_TYPES_INCLUDED_SCHEMAS=openai PG_META_DB_URL=postgresql://postgres:[email protected]:54322/postgres npm run gen:types:typescript

Against a Supabase instance where database is at postgresql://postgres:[email protected]:54322/postgres and has schema openai among others, types Table, TablesInsert, TablesUpdate, and Enums result in type errors because schema public is not defined.

What is the new behavior?

Against a Supabase instance where database is at postgresql://postgres:[email protected]:54322/postgres and has schema openai among others, types Table, TablesInsert, TablesUpdate, and Enums do not result in type errors.

Additional context

N/A.

[sweatybridge]

Hmm I think the concept here is to constrain each table to a new type on its own, for eg. PublicTableNameOrOptions type corresponds to the public schema exclusively.

We might need to generate separate export type Tables blocks depending on the schema name. @soedirgo wdyt?

[yingw787]

Ah sounds good! I was looking at that approach but since I don't personally use the new Table types I didn't know what the context of including them was. Happy to make this change (mapping over each schema to create the PascalCase Table types, and updating the typegen tests) and push up later this evening.

[yingw787]

@sweatybridge @soedirgo just pushed up some changes in order to create schema-specific types for Tables, TablesInsert, TablesUpdate, and Enums. Would love feedback on the source and test cases (should I add an additional test case to cover schemas not named public, and having multiple schemas)?

[sweatybridge]

After some thought, I think there's a backwards compatibility issue with this change. So I proposed a new approach in #723 and added you as the co-author.

We can close this PR if you are happy with it.

[sweatybridge]

This looks good to me. Will wait for @soedirgo's confirmation.

supersed by #723

[yingw787]

@sweatybridge mentioned in #723 I'm happy with those changes - I'll close this PR now. Thanks!