Re: Here's a fix to AbstractJdbc3Statement.getGeneratedKeys

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

In response to

Responses

Browse pgsql-jdbc by date

  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