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
Why don't you want to do the next:
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,
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?
In response to
pgsql-jdbc by date
|Next:||From: Do, Leon (Leon)||Date: 2007-01-22 20:54:26|
|Subject: Re: Max size for bytea type|
|Previous:||From: Michael Paesold||Date: 2007-01-22 13:37:51|
|Subject: Re: Synthesize support for Statement.getGeneratedKeys()?|