Re: [BUGS] BUG #14853: Parameter type is required even when the querydoes not need to know the type - Mailing list pgsql-bugs

From Pavel Stehule
Subject Re: [BUGS] BUG #14853: Parameter type is required even when the querydoes not need to know the type
Date
Msg-id CAFj8pRAEpC2qqzQpvErTQqqR-4aMNMQZmniCCuU07vNU8=bEPw@mail.gmail.com
Whole thread Raw
In response to Re: [BUGS] BUG #14853: Parameter type is required even when the querydoes not need to know the type  (Eduardo Pérez Ureta <edpeur@gmail.com>)
List pgsql-bugs
Hi

2017-10-16 7:40 GMT+02:00 Eduardo Pérez Ureta <edpeur@gmail.com>:
My example is even better!
There is no need to infer the type as it is not needed!
PostgreSQL should be able to infer that no type is needed.

PostgreSQL try to by type strict software. Sometimes the types can be detected from context, sometimes not. Somewhere this missing information is solved by type UNKNOWN, somewhere is raised a exception. Unfortunately there is not 100% consistency - some API is very strict, some less, some construct are very tolerant.

When you use a operator =, then unknown value should be casted to left side type.

postgres=# select 1=1;
 ?column?
----------
 t
(1 row)

postgres=# select 1='1';
 ?column?
----------
 t
(1 row)

postgres=# select 1='a';
ERROR:  invalid input syntax for integer: "a"
LINE 1: select 1='a';
                 ^
Regards

Pavel



On Oct 15, 2017 8:23 PM, "David G. Johnston" <david.g.johnston@gmail.com> wrote:
On Sunday, October 15, 2017, Eduardo Pérez Ureta <edpeur@gmail.com> wrote:
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

col1 has a type and so the type of the unspecified variable can be inferred.  Your is null example cannot have its typed inferred.

David J.

pgsql-bugs by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: [BUGS] Improper const-evaluation of HAVING with grouping sets and subquery pullup
Next
From: lelegaifax@gmail.com
Date:
Subject: [BUGS] BUG #14857: Typo in pg_dump italian translation