Re: [Fwd: Re: [Pljava-dev] char with trailing space, PreparedStatement.setObject
От | Thomas Hallgren |
---|---|
Тема | Re: [Fwd: Re: [Pljava-dev] char with trailing space, PreparedStatement.setObject |
Дата | |
Msg-id | 44A1A285.6000900@tada.se обсуждение исходный текст |
Ответ на | Re: [Fwd: Re: [Pljava-dev] char with trailing space, PreparedStatement.setObject (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [Fwd: Re: [Pljava-dev] char with trailing space, PreparedStatement.setObject
Re: [Fwd: Re: [Pljava-dev] char with trailing space, PreparedStatement.setObject |
Список | pgsql-jdbc |
Tom Lane wrote: > Thomas Hallgren <thomas@tada.se> writes: > >> Hmm, OK. I checked my code and I don't use any specific type. Instead, I >> use SPI_getargtypeid(ePlan, idx) on the prepared query and the >> pgType->typinput function of the type that corresponds to the returned >> oid. Perhaps the SPI_getargtypeid should return varchar for all text types? >> > > Certainly not. That would break most normal uses of SPI_getargtypeid, > and I don't even see how it fixes your problem; once the query is > prepared these decisions are already made. > > regards, tom lane > My problem is simple. When I pass a parameter with a trailing space, that space is considered significant. When the same thing is done using the client jdbc driver, the trailing space is insignificant. The client driver, since it knows nothing about the actual plan, elects to use the varchar type always. PL/Java uses the actual type that it gets from the plan when it performs the parameter coercion. I don't think my solution is wrong but it yields different results and that's undesirable. My questions stem from an uncertainty on how to go about fixing this so that the two drivers behave the same way (and for the same reason). Should this be considered a conscious flaw in the client driver motivated by the desire to limit the number of round trips? If it is, what would the best course of action be for me? Implement the same flaw although I don't have that problem? Regards, Thomas Hallgren
В списке pgsql-jdbc по дате отправления: