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

Duplicate property names #1

Open
sripberger opened this issue Aug 14, 2019 · 2 comments · May be fixed by #3
Open

Duplicate property names #1

sripberger opened this issue Aug 14, 2019 · 2 comments · May be fixed by #3

Comments

@sripberger
Copy link

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:

exports.STRING_DATA_RIGHT_TRUNCATION = '01004'

As well as here:

exports.STRING_DATA_RIGHT_TRUNCATION = '22001'

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.

@CMCDragonkai
Copy link

This is concerning. I'd like to see something deal with this properly.

@LinusU
Copy link
Owner

LinusU commented May 25, 2020

I'd be happy to make changes, but we would need a proposal on what to change to first...

I'd like to see something deal with this properly.

Do you have a suggestion on how to deal with this properly?

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

Successfully merging a pull request may close this issue.

3 participants