Skip to content

Error object differs between pg and pg-native #938

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

Closed
deyhle opened this issue Feb 15, 2016 · 3 comments
Closed

Error object differs between pg and pg-native #938

deyhle opened this issue Feb 15, 2016 · 3 comments
Milestone

Comments

@deyhle
Copy link

deyhle commented Feb 15, 2016

node-postgres abstracts over the pg-native module to provide exactly the same interface as the pure JavaScript version. No other code changes are required. If you find yourself having to change code other than the require statement when switching from require('pg') to require('pg').native please report an issue.

The fix for #743 made me test a switch to pg-native again. However, I still found an API difference: the Error object. While the default pg library returns an error with properties code and detail, the parameters are named differently when using pg-native.

require('pg'):

{
  "name": "error",
  "length": 199,
  "severity": "ERROR",
  "code": "23505",
  "detail": "Key (c1)=(one) already exists.",
  "schema": "public",
  "table": "dbhandlertest",
  "constraint": "dbhandlertest_pkey",
  "file": "nbtinsert.c",
  "line": "402",
  "routine": "_bt_check_unique"
}

require('pg').native:

{
  "severity": "ERROR",
  "sqlState": "23505",
  "messagePrimary": "duplicate key value violates unique constraint \"dbhandlertest_pkey\"",
  "messageDetail": "Key (c1)=(one) already exists.",
  "sourceFile": "nbtinsert.c",
  "sourceLine": "402",
  "sourceFunction": "_bt_check_unique"
}

This makes it hard to do proper error handling. Especially the code property is probably used a lot for that.

@brianc
Copy link
Owner

brianc commented Jun 6, 2017

Adding to the pg@7.0 release milestone to normalize these fields across the native bindings & the pure javascript library.

@vitaly-t
Copy link
Contributor

vitaly-t commented Jun 6, 2017

This makes it hard to do proper error handling. Especially the code property is probably used a lot for that.

In the meantime, the generic error handler can simply accept the native flag and parse errors differently.

brianc added a commit that referenced this issue Jun 9, 2017
Map native error properties to the same property names we use for errors from the JS driver.

Fixes #972
Fixes #938
brianc added a commit that referenced this issue Jun 9, 2017
* Add client connectionString tests (#1310)

* Remove redundant tests

* Add client connectionString test

Add test to ensure { connectionString } is respected as an argument to the client constructor

* Add test for connection string property

Also fixed some legacy require statements.

* Normalize native error properties

Map native error properties to the same property names we use for errors from the JS driver.

Fixes #972
Fixes #938
@brianc
Copy link
Owner

brianc commented Jun 9, 2017

I have this fixed on the 7.0 branch.

@brianc brianc closed this as completed Jun 9, 2017
brianc added a commit that referenced this issue Jun 9, 2017
* Add client connectionString tests (#1310)

* Remove redundant tests

* Add client connectionString test

Add test to ensure { connectionString } is respected as an argument to the client constructor

* Add test for connection string property

Also fixed some legacy require statements.

* Normalize native error properties

Map native error properties to the same property names we use for errors from the JS driver.

Fixes #972
Fixes #938
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

3 participants