Re: Synthesize support for Statement.getGeneratedKeys()?
От | Vit Timchishin |
---|---|
Тема | Re: Synthesize support for Statement.getGeneratedKeys()? |
Дата | |
Msg-id | 45B4C31A.7060304@gtech-ua.com обсуждение исходный текст |
Ответ на | Re: Synthesize support for Statement.getGeneratedKeys()? (Dave Cramer <pg@fastcrypt.com>) |
Список | pgsql-jdbc |
Hello. I have few thoughts I'd like to share. Everything below is my IMHO. First of all, parsing input DDL (or requiring protocol support) is needed to get full support for all range of DDLS. But now PostgreSQL does not support this feature for any DLLs. Then you can always detect is the support is needed on the first user call - depending on which function is called to prepare/execute the statement. Why don't you want to do the next: For PreparedStatement <http://java.sun.com/javase/6/docs/api/java/sql/PreparedStatement.html> *prepareStatement*(String <http://java.sun.com/javase/6/docs/api/java/lang/String.html>sql, int[] columnIndexes) throws SQLException <http://java.sun.com/javase/6/docs/api/java/sql/SQLException.html> (ans similar Statement call) simply call sql + " RETURNING *" and then filter out column indexes Of course, this won't handle the case when statement already contains RETURNING, cases for non-INSERT and so on (I am not an expert to describe all possible cases). But now NO cases are working and this change will make some work properly and I, personally, don't see a problem in others giving some other error message (say, incorrect SQL text for statements already containing RETURNING) then they are doing now. When the protocol will be changed (extended), you can use that but what does prevent you to implement the most widely used (as for me) case, given it will be implemented properly?
В списке pgsql-jdbc по дате отправления: