Skip to content

Unexpected results when querying a table called 'user' #28

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
pifantastic opened this issue Apr 25, 2011 · 2 comments
Closed

Unexpected results when querying a table called 'user' #28

pifantastic opened this issue Apr 25, 2011 · 2 comments

Comments

@pifantastic
Copy link

Queries to all other tables work as expected. When I query a table called 'user', it seems to return records from some other table, perhaps postgres' table internally representing database users.

  client.query("SELECT * FROM user", function(err, data) {
    console.log(client, err, data);
  });

returns

{ _queryQueue: [], _namedQueries: {}, _activeQuery: { text: 'SELECT * FROM user', values: [], callback: [Function], rows: [ [Object] ] }, _config: { database: 'mydb_development', user: 'mydbuser', password: 'mydbpass', host: undefined, port: 5432 }, _events: { connect: [Function], _row: [Function], _error: [Function], _readyForQuery: [Function] }, _connected: true } null { rows: [ { current_user: 'mydbuser' } ] }

However, if I duplicate my users table and name it differently, say 'user_copy', everything works as expected. The easy workaround is to just change the name of my user table.

@pifantastic
Copy link
Author

Gah, this appears to be a postgres thing and not related to your module. I apologize!

@pifantastic
Copy link
Author

As a follow up, what I was doing wrong: user is a reserved word in Postgres so a query like SELECT * FROM user returns the current database user. This is fixed by properly quoting the table name:

  client.query('SELECT * FROM "user"', function(err, data) {
    console.log(client, err, data);
  });

works as expected. TIL.

brianc added a commit that referenced this issue Dec 18, 2019
Do not send close after readyForQuery
brianc pushed a commit that referenced this issue Dec 27, 2019
* When connection fail, emit the error.

If client connect failed, emit the connection error  rather than swallowing it.

* Add test for connection error.
brianc pushed a commit that referenced this issue Dec 27, 2019
* Revert "When connection fail, emit the error. (#28)"

This reverts commit 6a7edab.

The callback passed to `Pool.prototype.connect` should be responsible for handling connection errors. The `error` event is documented to be:

> Emitted whenever an idle client in the pool encounters an error.

This isn’t the case of an idle client in the pool; it never makes it into the pool.

It also breaks tests on pg’s master because of nonspecific dependencies.

* Don’t create promises when callbacks are provided

It’s incorrect to do so. One consequence is that a rejected promise will be unhandled, which is currently annoying, but also dangerous in the future:

> DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

The way callbacks are used currently also causes #24 (hiding of errors thrown synchronously from the callback). One fix for that would be to call them asynchronously from inside the `new Promise()` executor:

    process.nextTick(cb, error);

I don’t think it’s worth implementing, though, since it would still be backwards-incompatible – just less obvious about it.

Also fixes a bug where the `Pool.prototype.connect` callback would be called twice if there was an error.

* Use Node-0.10-compatible `process.nextTick`
brianc pushed a commit that referenced this issue Apr 28, 2020
ssl=0 is now parses to false
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

1 participant