Re: BUG #18780: Bindings types are lost for complex queries

Viktor Remennik <vik(at)etogo(dot)net> writes:
> private static final String MERGE_QUERY = """
> merge into test as dst
> using (select ? as id,
> ? as ts,
> ? as amount) src
> on dst.id=?
> when matched then
> update
> set ts=src.ts,
> amount=src.amount
> when not matched then
> insert ("id", "ts", "amount")
> values (src.id, src.ts, src.amount)
> """;

That is never going to work, and you can complain all you want
but we're not going to accept it as a bug. The sub-select has
to decide on its output column types before parsing can proceed.
There is way too much semantic distance between there and where
it might be possible to discover that the output columns are
going to be assigned to particular target columns; furthermore,
the outer query might have other references to the sub-select's
columns that do not provide usable context for resolving their
types, or that provide conflicting hints.

The only cases like this that we support are

insert into sometable values (?)
insert into sometable select ?
update sometable set somecolumn = ?

where there is basically not anything between the unlabeled
parameter and its single use as an assignment source. (Even
these are undesirably messy internally.)

regards, tom lane