Open vibridi opened 4 years ago
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-queriesA
,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.