From: | rakesh at sptci(dot)com (Rakesh Vidyadharan) |
---|---|
To: | |
Subject: | [Pljava-dev] ResultSet getString |
Date: | 2006-05-18 14:38:33 |
Message-ID: | 7E60AAC2-554C-4541-B37D-C515957BE1DB@sptci.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | PostgreSQL : PostgreSQL 메일 링리스트 : 2006-05-18 14:38 이후 토토 결과. |
On 18-May-06, at 9:29 AM, Thomas Hallgren wrote:
> Marek Lewczuk wrote:
>>
>> Lets see what Java api say about ResultSet.getString():
>> "Retrieves the value of the designated column in the current row of
>> this ResultSet object as a String in the Java programming language."
>>
>> It doesn't say, that getString() will return "a string representation
>> of the object".
> Well, it has to, doesn't it? Either that or throw an exception.
> Question
> is, what representation?
>
>> Now, if I would like to get PostgreSQL String representation of
>> multi-dimensional array, what method should I use ?
> Simply perform SQL coercions in SQL rather than in Java, i.e. "SELECT
> array_out(arrayValue)". The array_out function will produce a pseudo
> type called cstring and PL/Java will treat that as a String.
>
>> For me obvious thing to do is to call getString() and I wouldn't
>> expect that this will return same as
>> ResultSet.getBoolean().toString(). Another example:
>>
>> Statement statement = ...
>> statement.execute()...
>> ResultSet result = ...
>> while (result.next()) {
>> // result contains 3 columns: varchar[], boolean, integer[]
>>
>> // we create a duplicated row, without worrying about the SQL type
>> Statement s = connection.createStatement();
>> s.executeUpdate("INSERT ... (c1, c2, c3) VALUES ('" +
>> result.getString(0) + "', '" + result.getString(1) + "', '" +
>> result.getString(2) + "')");
>> }
>>
> Try this instead:
>
> PreparedStatement s = connection.prepareStatement("INSERT ...(c1, c2,
> c3) VALUES(?,?,?)");
> s.setObject(result.getObject(1));
> s.setObject(result.getObject(2));
> s.setObject(result.getObject(3));
> s.executeUpdate();
>
> Far more efficient since:
> a) no String coercion is needed
> b) no String concatenation is needed
> c) the actual statement can be cached
> d) it's completely insensitive to the types of the involved columns.
>
> Regards,
> Thomas Hallgren
This is much more elegant. I had been doing something similar in the
earlier version while sending objects to the back-end by making my
custom objects extend PGobject. My SQL statements were much simpler
with just one parameter, doing s.setObject( 1, myObject, Types.OTHER )
Rakesh
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Hallgren | 2006-05-18 14:59:12 | [Pljava-dev] ResultSet getString |
Previous Message | Thomas Hallgren | 2006-05-18 14:29:14 | [Pljava-dev] ResultSet getString |