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

Ok, I understand, pg is just a simple opensource db, not a kinda "free oracle", and types processing after parsing is too much. Good.
But is it at least possible to throw an error then? Because currently such a queries are processed as they're "good". It's a bit inconsistent - either DB should process them or reject them. Now it is processing them sometimes with unpredictable results. Like, sometime it is working fine according to the standards, and sometimes it throws the exception I mentioned before. Like, "src.id<http://src.id>, src.ts, src.amount are unknown" or something of that sort.

Kind regards,
Viktor

On 20 Jan 2025, at 21:26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

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