From: | "JUNG, Christian" <christian(dot)jung(at)saarstahl(dot)com> |
---|---|
To: | "Kris Jurka" <books(at)ejurka(dot)com> |
Cc: | <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: PATCH: SET ROLE as connection parameter |
Date: | 2009-09-03 10:47:56 |
Message-ID: | 24BB5F92CE3E62419C5A6D5B1A1E0F46028E1B1C@nts58.saarstahl.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
> -----Original Message-----
> From: Kris Jurka [mailto:books(at)ejurka(dot)com]
> Sent: Wednesday, September 02, 2009 6:30 PM
> To: JUNG, Christian
> Cc: pgsql-jdbc(at)postgresql(dot)org
> Subject: Re: [JDBC] PATCH: SET ROLE as connection parameter
> 1) Can this be done in the V3 ConnectionFactoryImpl's
sendStartupPacket by
> adding it to the params array? If so that would save a network
roundtrip
> per connection that used this option.
I'm afraid that setting the role in the startup packet won't work. It's
only possible to change the role if the connection is in transaction
state (as far as I understand the GUC stuff in the backend code
correctly).
> want to support some, but not all of these options. If we're going to
do
> this one, we should probably bite the bullet and do search_path as
well
> because that's a pretty commonly requested item.
What's your opinion about the implementation?
Should the options be stored in a HashMap and the user be allowed to set
any key-/value-pair (no check if keys are allowed/mistyped, easy to use
new features) or should there be dedicated getter/setter (new features
have to be coded)?
bye
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Weimer | 2009-09-03 13:59:11 | Re: Search content within a bytea field |
Previous Message | Maciek Sakrejda | 2009-09-02 19:52:33 | Re: PGStream synchronization |