Fix types for "returning" methods

[santialbo]

Closes #4942
With the release of v1, the methods for returning changed a bit. However, the type definitions were not updated.

Reviewing the rest of the types I found that the onConflict clause was setting the Result type with the passed conflicting columns. This looked very strange and at least when using postgres as the backend, this is not the case.

Also, (this is another issue) when not using the "returning", the types specify that the result is number[]. However (at least using pg) a Result object is returned instead.

  const users = await knex
    .from<Contact>("contact").insert([{
      email: "xxxx@gmail.com",
      first_name: "jeff"
    }])
  // users is suposed to be a number[];
  console.log(users)
  // Result {
  //   command: 'INSERT',
  //   rowCount: 2,
  //   oid: 0,
  //   rows: [],
  //   fields: [],
  //   ...
  // }

[kibertoad]

why was debug added?

[santialbo]

it was a copy paste thing from the previous test, it's removed

[kibertoad]

Type tests are failing: https://github.com/knex/knex/runs/5271463571?check_suite_focus=true

[santialbo]

Type tests are failing: https://github.com/knex/knex/runs/5271463571?check_suite_focus=true

fixed, sorry I missed those.

[kibertoad]

is it no longer possible to have a more granular type here?

[santialbo]

It is possible but the type would be "wrong" anyways due to the issue that I mentioned before.
Insert/update methods without "returning" still have pre v1 signature of returning a number[] but they are not actually returning that. They return a "Result" object. I'm not sure if this is something that happens with just pg or it happens with every backend db.

  const users = await knex
    .from<Contact>("contact").insert([{
      email: "xxxx@gmail.com",
      first_name: "jeff"
    }])
  // users is suposed to be a number[];
  console.log(users)
  // Result {
  //   command: 'INSERT',
  //   rowCount: 2,
  //   oid: 0,
  //   rows: [],
  //   fields: [],
  //   ...
  // }

[kibertoad]

gotcha

[kibertoad]

thank you!

[KristjanTammekivi]

Can we have this released? It's a bit of a blocker for our knex upgrade

[kibertoad]

I will release it tomorrow

[esemeniuc]

This is still broken on knex.raw()