From: | Vit Timchishin <tivvpgsqljdbc(at)gtech-ua(dot)com> |
---|---|
To: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Synthesize support for Statement.getGeneratedKeys()? |
Date: | 2007-01-22 13:58:50 |
Message-ID: | 45B4C31A.7060304@gtech-ua.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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?
From | Date | Subject | |
---|---|---|---|
Next Message | Do, Leon (Leon) | 2007-01-22 20:54:26 | Re: Max size for bytea type |
Previous Message | Michael Paesold | 2007-01-22 13:37:51 | Re: Synthesize support for Statement.getGeneratedKeys()? |