Re: Prepared Statements - Mailing list pgsql-jdbc

From Dmitry Tkach
Subject Re: Prepared Statements
Date
Msg-id 3F1C0C2A.8090108@openratings.com
Whole thread Raw
In response to Re: Prepared Statements  (Csaba Nagy <nagy@ecircle-ag.com>)
Responses Re: Prepared Statements  (Csaba Nagy <nagy@ecircle-ag.com>)
List pgsql-jdbc
Csaba Nagy wrote:

>Well, looks like Dima's problem can be solved after all while still
>being standards compliant in the standard cases :-)
>Still, the individual data types should be validated and correctly
>escaped. If it counts at all, I would vote with this approach.
>Just one more question Dima, how will you at runtime that the current
>driver supports this functionality ? (for that matter, how do you know
>now ?)
>
I am not sure what you mean by 'runtime' in this context.

*At runtime* i just need to know *which* driver I am using. There is, of
course, still work to be done at the implementation stage to figure out
and implement the proper way of dealing with that driver. So, the way I
know is same as usual - by looking at the source and/or documentation of
the driver.

What I am avoiding is direct references to the vendor-specific
classes/packages (like org.postgresql.*), because, if I had those, the
code would not compile unless I have all the drivers available at
compile time. That's what I am trying to avoid.

I understand that I still have to know specifics of the drivers I
support, and have driver-dependent logic in the code, that uses the
right way to deal with the driver at runtime. But I am trying to keep
that logic independent from the actual driver implementation, so that it
does not require the driver to compile.

Dima


>
>Cheers,
>Csaba.
>
>
>
>
>>Oliver,
>>
>>I think Dima is arguing that Collection could be treated as an special case
>>where it indicates a list of something instead of a single something.
>>
>>So, we would iterate through this Collection using its iterator and, for each
>>Object obtained, act like a setObject has been used with that Object and the
>>JAVA TYPE as an argument.
>>
>>The Types.OTHER is used for database specific SQL types or for Dynamic Data
>>Access support.  As the Collection class is not a data type there is no chance
>>of confusion.
>>
>>It seems that Dima's idea can indeed work.
>>
>>Regards,
>>Fernando
>>
>>
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 8: explain analyze is your friend
>
>



pgsql-jdbc by date:

Previous
From: Fernando Nasser
Date:
Subject: Please adjust the subject [Was: Prepared Statements]
Next
From: Barry Lind
Date:
Subject: Re: Prepared Statements