I understand that not sending the type for a parameter (when it is not null) may not make much sense. But, currently PostgreSQL accepts parameters with unknown types in statements like: INSERT INTO t1 (col1) VALUES (?) SELECT * FROM t1 WHERE col1 = ?
where the column can be different types like VARCHAR or TIMESTAMP
What are the rules? When a parameter type is required and when it is not required? Do these rules come from the SQL standard or are PostgreSQL own?
It seems odd to me that there is no test coverage for this code, so this change cannot be accepted as it may break something else, that nobody currently knows.
I think PostgreSQL should be more consistent and either require types for non-null parameters or not require types for non-null parameters (and let the actual function or operator decide if the type is needed or not). This incoherency causes these problems.
The query: SELECT ? IS NULL should work even when the parameter type is unknown, as there is no need to know the type in that query.
While your statement is correct the behavior that all parameters must have a type is not buggy. As I'm not in a position to comprehend just how much could go wrong by removing that restriction (and making it work only in cases where type doesn't matter, like IS NULL, is unappealing) I'll forgo much speculation but will say that given that the error is both immediate and obvious the likelihood of changing this is quite low.
The PostgreSQL project has intentionally made a number of changes in the past that tighten up things in the area of types (unknowns and casting) with full awareness that those changes may break existing applications. It was felt that, on the whole, the benefit to future coders outweighed the inconvenience of a subset of the existing code.