You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Until recently, pg driver supported only a global definition for converting SQL types returned from queries into JS types. Therefore users had to try and find a global configuration matching their needs.
For example, for supporting a high-precision float arithmetic in a specific query, a developer might need to use a custom converter into a JS high-percision number type. Since the conversion configuration in pg used to be global (per returned SQL type), the configured conversion would necessarily apply to any other query returning the same SQL data type, regardless of whether such a conversion is needed or convenient for developers.
Since version 7.10, released in April 2019, it's possible to customize the type conversion function per query, like so:
constquery={text: 'SELECT * from some_table',types: {getTypeParser: ()=>val=>val,},}
It would be useful for knex to support passing this per-query configuration when executing an SQL query on top of pg.
Applies to: Postgres with pg driver >= 7.10
Until recently,
pg
driver supported only a global definition for converting SQL types returned from queries into JS types. Therefore users had to try and find a global configuration matching their needs.For example, for supporting a high-precision float arithmetic in a specific query, a developer might need to use a custom converter into a JS high-percision number type. Since the conversion configuration in
pg
used to be global (per returned SQL type), the configured conversion would necessarily apply to any other query returning the same SQL data type, regardless of whether such a conversion is needed or convenient for developers.Since version 7.10, released in April 2019, it's possible to customize the type conversion function per query, like so:
It would be useful for knex to support passing this per-query configuration when executing an SQL query on top of
pg
.A possible API for this in Knex could be:
The text was updated successfully, but these errors were encountered: