Re: BUG #14853: Parameter type is required even when the query does not need to know the type

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.

Is anybody interested in fixing this issue?

2017-10-13 15:38 GMT+00:00 David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>:

> On Fri, Oct 13, 2017 at 7:03 AM, <edpeur(at)gmail(dot)com> wrote:
>
>> The following bug has been logged on the website:
>>
>> Bug reference: 14853
>> Logged by: Eduardo Perez
>> Email address: edpeur(at)gmail(dot)com
>> PostgreSQL version: Unsupported/Unknown
>> Operating system: All
>> Description:
>>
>> 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.
>
> David J.
>