>If the server's parser tries to guess a type, that will simply move the
>pain from this case to other cases, namely those where the choice
really
>matters and it guesses wrong.
Well, the server already guesses parameter types, no? In a Parse
protocol message, any parameter type specification is optional. If you
leave it out, the server guesses for you (and tells you about it in the
ParameterDescription message). This is just about making the server
smarter.
JDBC spec or no, having the server process
"SELECT NULL IS NULL"
but balk at
"SELECT $1 IS NULL" ($1 = NULL)
is pretty silly. The type system is working against us here. I
understand that due to planning and so on, this leads through two very
different code paths, but I think the complaint is fundamentally sound.
Whether it's worth addressing is a separate issue, and there's also the
question of whether addressing it will resolve Bernard's complaint (I
decided not to pursue it last time because I felt it would not; maybe
I'm wrong).
>Having said that, it's interesting to wonder how much would break if
>setObject were to arbitrarily assume the data type is TEXT.
I take it you mean "assume TEXT if the parameter is a Java null?" If the
parameter is not null, the type system gives the driver enough
information to do some mapping based on the Java type of the parameter.
I tried this and one of the JDBC tests fails, but it may still be worth
considering. My (trivial) change is here:
https://github.com/deafbybeheading/pgjdbc/tree/null-parameter-type
The test that breaks is the following:
https://github.com/deafbybeheading/pgjdbc/blob/master/org/postgresql/tes
t/jdbc2/ArrayTest.java#L48
The code in the test is a simple NULL insert with no additional type
information. Should we avoid breaking that? I have no particularly
strong feelings there either way, but it indicates this won't be a
"free" change.
-Maciek
