Re: Here's a fix to AbstractJdbc3Statement.getGeneratedKeys

Поиск
Список
Период
Сортировка
От Kris Jurka
Тема Re: Here's a fix to AbstractJdbc3Statement.getGeneratedKeys
Дата
Msg-id Pine.BSO.4.64.0904241317220.24989@leary.csoft.net
обсуждение исходный текст
Ответ на Here's a fix to AbstractJdbc3Statement.getGeneratedKeys  (Jeppe Sommer <jso@trifork.com>)
Ответы Re: Here's a fix to AbstractJdbc3Statement.getGeneratedKeys  (Thomas Kellerer <spam_eater@gmx.net>)
Re: Here's a fix to AbstractJdbc3Statement.getGeneratedKeys  (Jeppe Sommer <jso@trifork.com>)
Список 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

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: John Lister
Дата:
Сообщение: Re: JDBC problem with dates and ANYELEMENT type
Следующее
От: Thomas Kellerer
Дата:
Сообщение: Re: Here's a fix to AbstractJdbc3Statement.getGeneratedKeys