Kris Jurka skrev:
> On Sat, 25 Apr 2009, Jeppe Sommer wrote:
>
>
>> So what you are saying is that ResultSetMetaData.isAutoIncrement will only
>> return true for a subset of the fields that are actually autogenerated? But
>> perhaps it could serve as a starting point.. The jdbc apidoc is not very
>> precise on what constitutes an autogenerated key, maybe
>> autogenerated=autoincrement is even a valid interpretation?
>>
>
> Yeah, it doesn't really say anything about what autogeneratedkeys are. I
> would take auto-generated to mean, "any field that gets a value that
> wasn't directly provided." That would include defaults and things set by
> triggers. I would take key to mean "any field that's part of an index."
> But putting these together doesn't seem to make a whole lot of sense.
> Would you not return a value generated by a serial column just because it
> didn't have an index on it? Given that it's poorly defined and because I
> wanted to avoid having to parse the provided query, what's been done is to
> just return everything possible and let the caller deal with it. If the
> data isn't there, the caller can't do anything about it. If there's too
> much, the caller can just ignore it.
>
However, this strategy is only helpful with applications/frameworks that
can be customized to work with PostgreSQL. You have to build key
filtering into the application.
>
>> I'm not trying to improve performance, only to get the correct behaviour. I
>> introduced the filtering because the application (actually the Spring
>> framework) failed on receiving all fields when it was expecting only the
>> generated field(s).
>>
>>
>
> Failed how (a stacktrace for example), perhaps it would be better to fix
> Spring?
>
I'm sorry, I don't have a stacktrace any more. From memory, what failed
was GeneratedKeyHolder.getKey(), throwing an exception on receiving more
than one key (code can be viewed here:
http://www.devdaily.com/java/jwarehouse/spring-framework-2.5.3/src/org/springframework/jdbc/support/GeneratedKeyHolder.java.shtml).
Again, if you are writing for PostgreSQL you could use the getKeys
method instead of getKey and do the filtering yourself. But for an
application/framework that tries to stay portable, thats not a good option.
> Also, I thought of an issue with your patch. It will only work when using
> the V3 protocol. When connected to a server via V2, we don't get the base
> table information, ResultSetMetaData.isAutoIncrement will always return
> false.
>
From my point of view, it seems ok that improvements are only supported
in newer versions of PostgreSQL. If someone prefers to have all keys
returned when this metadata info is not available, some graceful
degradation could be built into the driver.
> Kris Jurka
>
Jeppe
