Neil:
I think that general use of this feature should be enabled using the
URL, not with an API call. We use a JDBC connection pool and it will
help tremendously to have the pool set to user server-side preparing
without having to downcast the connection to a PG connection (which I
think is an issue because of the facade in our connection pool code).
The second item is that of compatibility. If the new code cannot handle
all statements (eg. something with a semi in it) and disable the
generation of a 'prepare' then we cannot count on the URL functionality.
As I understand it, the programmer is required currently to
enable/disable the server-side functionality by hand and only when the
statement to be prepared is not composite (statement1; statement2;
statement2).
But in our real-world application space, we use a connection pool with a
facade, so getting to the actual connection to enable this is
problematic (and forces postgresql-specific coding into our framework
where it is not particularly welcome). If we overcame this issue, we
would then need to hand-manage the enable/disable to only be used when
the statement is appropriately formulated (e.g., no semicolons in the
statement).
If we could get URL enabling and auto-detection of statements that won't
work (and hence disable the enabled function for these functions), I
think we have a solution that can be deployed into 'generic' app server
environments with just configuration changes. That is, an operations
person could enable this feature and monitor its impact on performance
to see if/how it helps. That is a BIG win (at least to me) and a HUGE
marketing item. I'd love to test MySQL with some joins over JDBC with
PostgreSQL with some joins using prepared statements and be able to
demonstrate the big improvement that this makes.
As I understand it, the functions I am waiting for are targeted into 7.4
(but I'd love to see them early and do some testing of those for the
community).
Charlie
Neil Conway wrote:
>On Fri, 2003-01-03 at 17:16, Charles H. Woloszynski wrote:
>
>
>>I think the functionality is starting to become real, but it looks like
>>it is starting with some limitations that might restricts its use from
>>be maximally realized until 7.4 (or beyond).
>>
>>
>
>Specifically, which limitations in this feature would you like to see
>corrected?
>
>Cheers,
>
>Neil
>
>
--
Charles H. Woloszynski
ClearMetrix, Inc.
115 Research Drive
Bethlehem, PA 18015
tel: 610-419-2210 x400
fax: 240-371-3256
web: www.clearmetrix.com