Kris Jurka skrev:
> On Fri, 24 Apr 2009, Jeppe Sommer wrote:
>> Porting a project from MySQL to PostgreSQL, I discovered that the jdbc3
>> facility of returning the generated keys from an insert statement does not
>> work. On a fresh cvs checkout, there is partial support, however, all fields
>> are returned, not only the field that are autogenerated.
> The problem is knowing what fields are autogenerated. A field that simply
> has a default value may in fact be autogenerated. Also, what about a
> before trigger which sets that value, that's also autogenerated.
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?
>> Here is a patch that fixes this. I hope someone will take a look, and
>> consider whether it can be adopted into the project. Or improved. It works
>> for me :-)
>> The strategy of the patch is simply to inspect the metadata of the returned
>> (initially full) resultset, and then strip out any fields that are not marked
>> as autoincrement.
> I don't see how this helps. If it was able to avoid returning all fields
> to the client, you could see how it would be a performance improvement,
> but returning them all and then filtering is just adding more time isn't
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).
> Kris Jurka
In response to
pgsql-jdbc by date
|Next:||From: Kris Jurka||Date: 2009-04-27 17:35:01|
|Subject: Re: Here's a fix to AbstractJdbc3Statement.getGeneratedKeys|
|Previous:||From: Peter||Date: 2009-04-25 05:32:21|
|Subject: Re: JDBC problem with dates and ANYELEMENT type|