Re: get/setReadOnly broken if default_transaction_read_only on

On 06/07/2012 06:50 AM, Craig Ringer wrote:
>
> This may be an opportunity to improve how PgJDBC finds out important
> details about the backend in general.
>
> Right now, lots of things require individual queries of GUCs via SHOW
> commands or other misc queries. A typical JDBC session may do several
> round trips before running its first real query, and it's only going to
> get worse.
> ...
> (Why extensibility? Because various layers - ORMs, query builders, etc
> etc etc - tend to ask for more GUCs, and having the JDBC driver able to
> immediately return them without more round trips would be great).

I certainly like that idea, but I hope someone won't mind doing the
quick, current-practice fix for setReadOnly() meanwhile. There may
be a large and growing set of new layers that all want more GUCs,
but by contrast the set

{ x | x is defined by jdbc2 and doesn't currently work }

is smaller and bounded, and getReadOnly/setReadOnly are in it.

I'd submit a patch myself but this is really my first time looking
at the code, I haven't set up a development workspace, and I'm
hoping there's someone who could commit in 5 minutes what I'd be
tinkering with much of the day while I learn.

-Chap

> On 06/07/2012 04:11 AM, J Chapman Flack wrote:
>>
>> Hi,
>>
>> I've found this in the git head so it applies to current versions.
>>
>> AbstractJdbc2Connection initializes its readOnly member to a
>> hardcoded false instead of to 'show default_transaction_read_only'
>> from the backend.
>>
>> That means two things: 1. getReadOnly() is wrong in case the
>> backend has default_transaction_read_only on, and
>>
>> 2. setReadOnly(false) doesn't work in that case, because the value
>> is compared to readOnly and looks the same, so no set session
>> characteristics command is sent to the backend.
>>
>>
>> An application can work around (2) by always calling
>> setReadOnly(true);setReadOnly(false); if it wants to write.
>> But that's a bit ugly.
>>
>> The driver could do that too for a quick hack, but it would
>> be nice to query the correct value from the backend and use that.