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
Something I've just noticed while trying to add types for this on DefinitelyTyped (not really necessary by any means but I'm kind of a stickler for that kind of stuff).
You've exported duplicate property names with varying values more than once in several places. For example STRING_DATA_RIGHT_TRUNCATION is defined both here:
As we can see, the former value ('01004') differs from the latter ('22001'). Obviously this will end up just overwriting the former with the latter, so that the former is not available to consumers of the package.
I'm assuming this package was created by simply copying the table directly from the postgres docs, which features the same table and the same duplicate condition names.
The duplicate condition names in postgres docs seem to indicate that quite often multiple different codes map to a single condition code. If that's the case, then the approach of checking error.code against a single string constant with === cannot be reliable:
const { STRING_DATA_RIGHT_TRUNCATION } = require('pg-error-constants')
if (err.code === STRING_DATA_RIGHT_TRUNCATION) {
// This will fail to identify the '01004' code.
}
I suppose you could export these as arrays of strings and alter consuming code to check for array membership. Or possibly provide some kind of utility function for doing the check. Either way it would probably require some major breaking changes, and to some extent it might not even make sense to suffix such a module with -constants.
I've found these constants pretty helpful so far, so I'd be happy to contribute such changes if you're open to them.
The text was updated successfully, but these errors were encountered:
Something I've just noticed while trying to add types for this on DefinitelyTyped (not really necessary by any means but I'm kind of a stickler for that kind of stuff).
You've exported duplicate property names with varying values more than once in several places. For example
STRING_DATA_RIGHT_TRUNCATION
is defined both here:pg-error-constants/index.js
Line 11 in 5cb96f1
As well as here:
pg-error-constants/index.js
Line 93 in 5cb96f1
As we can see, the former value ('01004') differs from the latter ('22001'). Obviously this will end up just overwriting the former with the latter, so that the former is not available to consumers of the package.
I'm assuming this package was created by simply copying the table directly from the postgres docs, which features the same table and the same duplicate condition names.
The duplicate condition names in postgres docs seem to indicate that quite often multiple different codes map to a single condition code. If that's the case, then the approach of checking
error.code
against a single string constant with===
cannot be reliable:I suppose you could export these as arrays of strings and alter consuming code to check for array membership. Or possibly provide some kind of utility function for doing the check. Either way it would probably require some major breaking changes, and to some extent it might not even make sense to suffix such a module with
-constants
.I've found these constants pretty helpful so far, so I'd be happy to contribute such changes if you're open to them.
The text was updated successfully, but these errors were encountered: