Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow the default type map to be overrided from config #146

Closed
adelsz opened this issue Jul 25, 2020 · 2 comments
Closed

Allow the default type map to be overrided from config #146

adelsz opened this issue Jul 25, 2020 · 2 comments
Assignees

Comments

@adelsz
Copy link
Owner

adelsz commented Jul 25, 2020

Config should have a new typeMap field:

{
  typeMap: {
    bigint: 'number' | 'bigint' | 'string',
    interval: 'iso-string' | 'interval' | 'string'
  }
}

This field allows to select a parser and type for each postgres type passed and returned.
pgTyped will then automatically handle parsing this type at both runtime and compile-time.

@logan12358
Copy link
Contributor

This mapping can be achieved in node-postgres with the pg.types.setTypeParser mechanism. If I understand correctly, the BigInt mapping might become default for node-postgres in the future: brianc/node-pg-types#78.

pgtyped implicitly relies on the type mappings of whichever IDatabaseConnection is used. Do you know if it's common to use backends other than node-postgres to provide IDatabaseConnection?

I think two big options are:

  1. Support configuration over which types are emitted, but don't do runtime conversion. Add documentation for configuring backends to match.
  2. Integrate more tightly with node-postgres and automatically set the client's type parser (following https://github.com/adelsz/pgtyped/milestone/1, I guess)

@adelsz
Copy link
Owner Author

adelsz commented Jan 29, 2023

Implemented by #476

@adelsz adelsz closed this as completed Jan 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants