Re: Types pollution with unknown oids and server-side parameters binding

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Tue, May 3, 2022 at 3:35 PM Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
> wrote:
>> Looking at the above variation of the problem, maybe the right thing
>> to do would be to throw an error because the parameter can be
>> interpreted in different ways in different places? I seem to
>> understand, from David's example, that such an error is thrown, in
>> other contexts.

> That horse has already left the barn.

Well, perhaps not. It's certainly not great that the behavior depends
on non-obvious implementation details. I could imagine changing to
a rule that says "if an unknown-type parameter is referenced more than
once, we must infer the same type for it at each of those places",
rather than "first one in parsing order wins".

What's not very clear is whether such a change would make more people
happy than sad. It'd almost inevitably break some queries that had
coincidentally gotten the behavior their authors wanted. But the
key word there is "coincidentally", I suspect.

> I do
> think that trying to clarify "first" better, since it's not the
> in-your-face textual order that is being used.

I'm not thrilled with having to document the parsing order, especially
since it's arbitrary in some places (e.g., why RETURNING before the
UPDATE list --- that doesn't seem to make a lot of sense).

regards, tom lane