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

Re: PATCH: SET ROLE as connection parameter

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 (view raw or flat)
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

In response to

pgsql-jdbc by date

Next:From: Florian WeimerDate: 2009-09-05 14:06:07
Subject: Re: Search content within a bytea field
Previous:From: Emanuel CoutoDate: 2009-09-03 19:32:52
Subject: Error in webpage

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