Skip site navigation (1) Skip section navigation (2)

Re: get/setReadOnly broken if default_transaction_read_only on

From: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
To: Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Johann 'Myrkraverk' Oskarsson <johann(at)2ndquadrant(dot)com>, PostgreSQL JDBC <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: get/setReadOnly broken if default_transaction_read_only on
Date: 2012-06-10 03:18:50
Message-ID: 4FD4121A.3020000@ringerc.id.au (view raw or flat)
Thread:
Lists: pgsql-jdbc
On 06/09/2012 12:52 AM, Maciek Sakrejda wrote:
> On Fri, Jun 8, 2012 at 6:47 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us>  wrote:
>> There already is a mechanism to notify clients of changes in selected
>> GUC settings, but currently the set of parameters so reported is
>> hard-wired.  Possibly pgsql-hackers would consider a proposal to let
>> the GUC_REPORT flag get set on client-selected parameters.
> Somewhat off-topic, but along the same lines, it would also be worth
> considering some mechanism to give the driver visibility into catalog
> changes w.r.t. UDTs. I.e., right now, the only way for the driver to
> sanely support custom types is to query the catalog for the oid of a
> specific type name. However, if that type is subsequently dropped and
> re-created and gets a different oid, the driver has no idea.
> Unfortunately, I don't think there's a great way to support that
> without protocol changes (whereas for the reporting flag, that's not
> an issue).

Is there currently a page with a list of changes to be included in the 
next protocol revision? I could've sworn there was one around, but cant' 
seem to find it. If there isn't, I'll pop one up on the wiki and link to 
it from the todo.

Should put capability flags on the list too. So many difficult decisions 
about defaults (like the bytea format issue) would be simplified by 
having clients send a capability flag set. "Yup, I know about 'hex' 
format bytea."

--
Craig Ringer

In response to

pgsql-jdbc by date

Next:From: Craig RingerDate: 2012-06-10 03:39:05
Subject: Re: Hung JDBC connections
Previous:From: wbranaDate: 2012-06-09 11:25:42
Subject: An I/O error occured while sending to the backend

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group