On 05/26/18 15:22, Andrew Gierth wrote: > So what I'm thinking now is that the way to go, if one wants to imitate > the client-side protocol behavior closely, would be to have a setup hook > that calls parse_variable_parameters the first time, and then > parse_fixed_parameters on subsequent calls for revalidation.
What circumstances would call for revalidation, and what would it be able to accomplish, under that design? I'm kind of trying to think out what the semantics could be in PL/Java, should they be changed from what they are now (which is just to tell you all params are varchar until you have supplied values for them, and then tell you what types you supplied, in case you'd forgotten). It's interesting that with parse_variable_parameters, it is possible to supply some types explicitly, while leaving others to be inferred. In one plausible implementation, that could be what would happen in PL/Java if you called prepareStatement(), then called setter methods on a few of the parameters, then called getParameterMetaData(). And I suppose there could be cases where the explicitly supplied types for some parameters would affect the types that get inferred for others. On one hand, that sounds like it could be a bit confusing, and on the other, sounds like it might be useful sometimes and I should just embrace my inner Schrödinger and say yeah, that's how it works, you 'collapse' the type assignments to whatever fits best at whatever moment you call getParameterMetaData(). >From a glance at the (network client) pgjdbc code, that seems to be what you'd expect to happen there, too; it gets sent to the backend for "describe only" at the moment getParameterMetaData is called. What I can find of the JDBC spec seems informal and breezy about this stuff to an unsettling degree.... -Chap
