Re: [BUGS] BUG #14853: Parameter type is required even when the query does not need to know the type
От | Tom Lane |
---|---|
Тема | Re: [BUGS] BUG #14853: Parameter type is required even when the query does not need to know the type |
Дата | |
Msg-id | 18575.1508178836@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14853: Parameter type is required even when the querydoes not need to know the type (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: