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
