Consider extending instead of mutating?

[uniibu]

As the title says, consider extending pg.Pool and pg.Client instead of mutating them and storing them on a separate property of pg.
For example for pg.Client

//assuming module pg is already passed
pg._Client = class extends pg.Client {
  constructor (opts) {
    super(opts)
  }
  _query (...args) {
   return super.query(...args)
  }
  query (statement,_,cb) {
      if (typeof cb === 'function') {
        return this._query.apply(this, arguments);
      }
     if (!(statement instanceof SqlStatement)) {
      Promise.reject(new Error('must build query with sql or _raw'));
     }
     return this._query(statement);
  }
  // other helpers here...
}

Since it now uses pg._Client, this would be a major update because of the breaking changes. In this way, you avoid mutating the original class, and still prevents accidental sql injection, assuming user uses new pg._Client() instead of the original new pg.Client()

As for pg.Pool, until this brianc/node-postgres#1541 pull request gets merged, You would need to directly extend pg-pool yourself.
For example for pg.Pool:

const PgPool = require('pg-pool');
//assuming module pg is already passed
// pg._Client must come first before extending pg.Pool
pg._Pool = class extends PgPool {
  constructor (opts) {
   // requires node 8+ , use Object.assign for node 7. 
    super({ Client: pg._Client, ...opts })
  }
  _query (...args) {
   return super.query(...args)
  }
  query (statement,_,cb) {
      if (typeof cb === 'function') {
        return this._query.apply(this, arguments);
      }
     if (!(statement instanceof SqlStatement)) {
      Promise.reject(new Error('must build query with sql or _raw'));
     }
     return this._query(statement);
  }
  // other helpers here...
}

The same thing with pg._Client, user will now have to use pg._Pool and this breaks and should be a major update.
On both implementation, user are still able to access the original/non-mutated pg.Pool and pg.Client

Another approach without breaking changes would be to clone pg.Pool and pg.Client to pg._Pool and pg._Client and extend pg.Pool and pg.Client instead. This way, _Pool and _Client will serve as the original/non-mutated classes.

[danneu]

Good idea.

Maybe pg.extra.{Client,Pool} to make it more obvious.

After all, I don't think it's common to be creating Clients/Pools frequently by hand so there aren't too many opportunities to create a pg.Pool when user meant pg._Pool/pg.extra.Pool.

[uniibu]

pg.extra.{Client,Pool} would also work yes, and yeah usually, new Pool is only used once while new Client is often used inside a helper function. Anyway, i really suggest this way instead of mutating the original classes, which would leave more freedom and space for users to do what they want with the original classes.

[danneu]

Agreed. It's been the main defect of this library and something I wasn't happy with.

I'm currently taking a break from programming for a month or two.

If you have the motivation, energy, and were thinking of submitting a PR, I certainly would be interested.

[danneu]

TODO: Update readme and publish major point release.

[danneu]

Alright, updated readme and published 2.x.

https://github.com/danneu/koa-skeleton was updated to use pg-extra 2.x.

Thanks again.