From: | Kris Jurka <books(at)ejurka(dot)com> |
---|---|
To: | Jeppe Sommer <jso(at)trifork(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Here's a fix to AbstractJdbc3Statement.getGeneratedKeys |
Date: | 2009-04-24 17:20:48 |
Message-ID: | Pine.BSO.4.64.0904241317220.24989@leary.csoft.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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.
> 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
it?
Kris Jurka
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Kellerer | 2009-04-24 17:33:20 | Re: Here's a fix to AbstractJdbc3Statement.getGeneratedKeys |
Previous Message | John Lister | 2009-04-24 09:05:23 | Re: JDBC problem with dates and ANYELEMENT type |