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

For postgres, applying type information to a bind variable does not work. #18

Closed
besk-cerity opened this issue Apr 15, 2020 · 4 comments

Comments

@besk-cerity
Copy link

I encountered this issue when using an ANY function as a replacement for an IN clause. I created a mocha test to illustrate the problem:

it('pg bind array using ANY clause with type cast', () => {
  const query = 'SELECT id::int FROM user WHERE id=any(:idList::int[]) and born > :year;'
  const data = {idList: [1, 2, 3], year: 2000}
  const expected = {
    text: 'SELECT id::int FROM user WHERE id=any($1::int[]) and born > $2;',
    values: [[1, 2, 3], 2000]
  };
  assert.deepEqual(yesql.pg(query)(data), expected)
})

This used to work when we were using v3.2.2.

@besk-cerity
Copy link
Author

I had thought this was strictly an issue with casting to an array (I suspected the [] was throwing off the regex matching), but it will similarly fail any time you associate casting with a bind variable. This test will also fail:

it('pg bind variable with type cast', () => {
  const query = 'SELECT id::int FROM user WHERE id=:id::int and born > :year;'
  const data = {id: 1, year: 2000}
  const expected = {
    text: 'SELECT id::int FROM user WHERE id=$1::int and born > $2;',
    values: [1, 2000]
  };
  assert.deepEqual(yesql.pg(query)(data), expected)
})

@pihvi
Copy link
Owner

pihvi commented Apr 19, 2020

Thanks for the excellent bug report!
I'm working on this to bring back the same logic from version 3.

@pihvi
Copy link
Owner

pihvi commented May 21, 2020

Well finally I got this solved with a proper solution. So the old v3 logic is back and the new feature (quoted strings), that broke this in the first place, is now properly supported.

Can you verify this also solved your issue in version 4.1.2?

@pihvi pihvi closed this as completed May 21, 2020
@besk-cerity
Copy link
Author

Thanks. A quick test seems to indicate this works for us.

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

2 participants