Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> In other words, the fact that "make check" passes may easily be just due
> to an omission in the regression tests. Apparently there's no test that
> we actually produce the error when the type can't be inferred.
> That being said, I don't know if this is a correct change or not.
The patch as presented (ie, just remove the check that all types
got determined) has no chance whatsoever of being accepted. The
reason that check exists is that client-side code isn't necessarily
going to cope with being told that a parameter it is supposed to supply
is of type "unknown". psql doesn't really care (in fact I don't think
it uses parameters at all), which is why the core regression tests pass.
But other clients such as JDBC have considerably more logic that depends
on the types of parameters. We're not going to risk breaking them for
this sort of dubious-in-any-case feature.
It's possible that we'd accept a patch that resolves the parameter
as type text if it's in a context where the type doesn't matter.
(Are there any such contexts other than IS [NOT] NULL?)
Arguably that's more consistent with the fact that we now resolve
"select $1" as being type text. But I'm not sure if that breaks any
cases that work today. The obvious counterexample is something like
prepare foo as select $1 is not null and $1 > 42;
where the parameter would need to be resolved as some other type later.
But that presently fails with "could not determine data type", so I don't
see a very good reason why "operator does not exist: text > integer" is
a worse outcome. The sticking point would be whether there are related
cases that succeed but such a patch would cause them to fail (or
silently change behavior, which is likely worse).
> You'll need to submit it to pgsql-hackers though.
Yes, this is certainly not a bug but a RFE.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs