From: | Kris Jurka <books(at)ejurka(dot)com> |
---|---|
To: | "JUNG, Christian" <christian(dot)jung(at)saarstahl(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: PATCH: SET ROLE as connection parameter |
Date: | 2009-09-04 00:49:49 |
Message-ID: | alpine.BSO.2.00.0909031941040.19087@leary.csoft.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On Thu, 3 Sep 2009, JUNG, Christian wrote:
> sendStartupPacket by
>> adding it to the params array? If so that would save a network
>> -----Original Message-----
>> 1) Can this be done in the V3 ConnectionFactoryImpl's
> 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).
Hmm, it looks like this works on CVS HEAD, but not before that. It must
be related to the removal of flatfiles.c. We can't make any version
specific decisions prior to establishing a connection, so we can't do it
in the startup packet, but I think it should still be in the
ConnectionFactory code. For the V2 Protocol it can be done in the
existing network trip done by runInitialQueries.
> 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)?
The previous discussion was that this wouldn't work for Datasources which
have to be accessed in a Java-Bean(y) way, so they can only take simply
parameters, not a Map. So I'd just do role and search_path for the moment
because we don't have any good ideas on how a general solution would work.
Kris Jurka
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Weimer | 2009-09-05 14:06:07 | Re: Search content within a bytea field |
Previous Message | Emanuel Couto | 2009-09-03 19:32:52 | Error in webpage |