You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is more of a question than an actual bug report:
Code Example
funcdoQuery(...) ([]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.
The text was updated successfully, but these errors were encountered:
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
This is more of a question than an actual bug report:
Code Example
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 param2
, and$3
to bind to the third parambar
.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
andC
, where:A
contains a$1
placeholderB
andC
don'tQ
might be either onlyA
,A U B U C
orB U C
according to a bunch ofif
conditions.So the params
$2, $3, $x
are the same in allA
,B
,C
chunks, except thatA
has also$1
.I would like to hear your opinion on this.
The text was updated successfully, but these errors were encountered: