Re: PATCH: SET ROLE as connection parameter
От | Kris Jurka |
---|---|
Тема | Re: PATCH: SET ROLE as connection parameter |
Дата | |
Msg-id | alpine.BSO.2.00.0909031941040.19087@leary.csoft.net обсуждение исходный текст |
Ответ на | Re: PATCH: SET ROLE as connection parameter ("JUNG, Christian" <christian.jung@saarstahl.com>) |
Список | 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
В списке pgsql-jdbc по дате отправления: