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

Skip binding of missing parameter placeholders #969

Open
vibridi opened this issue May 20, 2020 · 1 comment
Open

Skip binding of missing parameter placeholders #969

vibridi opened this issue May 20, 2020 · 1 comment

Comments

@vibridi
Copy link

vibridi commented May 20, 2020

This is more of a question than an actual bug report:

Code Example

func doQuery(...) ([]interface{}, error) {
	args := []interface{}{
		"foo",
		2,
		"bar",
	}
	query := `
SELECT * FROM my_table m WHERE m.count = $2 AND m.title = $3
`
	db.SelectContext(ctx, dest, query, args...)
}

Here I have a query with three arguments but only two parameter placeholders, starting from $2.

Expected
Not sure if it's reasonable to expect this: intuitively, I would like simply $2 to bind to the second param 2, and $3 to bind to the third param bar.

Actual
pq: could not determine data type of parameter $1 (even though there's no $1 param in the source query).

Of course it's reasonable that the lib complains about mismatches between input arguments and placeholders, but I also wonder if it would equally make sense to handle this case more gracefully; i.e. as long as the length of args is >= the highest number among placeholders, it might as well not fail.

Use Case
My use case is a big query with a few UNION'ed blocks that is composed dynamically.
Let's say I have three main sub-queries A,B and C, where:

  • A contains a $1 placeholder
  • B and C don't
  • the composed query Q might be either only A, A U B U C or B U C according to a bunch of if conditions.
    So the params $2, $3, $x are the same in all A,B, C chunks, except that A has also $1.

I would like to hear your opinion on this.

@johto
Copy link
Contributor

johto commented Jun 16, 2020

Of course it's reasonable that the lib complains about mismatches between input arguments and placeholders, but I also wonder if it would equally make sense to handle this case more gracefully; i.e. as long as the length of args is >= the highest number among placeholders, it might as well not fail.

The server doesn't accept it, so this is a non-starter:

=# prepare qwr as select $2;
ERROR:  could not determine data type of parameter $1

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