Обсуждение: PATCH: SET ROLE as connection parameter

Hi,

here's a small patch to set the role at connection time (parameter "role"). The patch was made against the current
CVS-version.


bye
Chris

--
phone: +49 6898/10-4987
web  : www.saarstahl.de
mail : Hofstattstraße 106a
       D 66333 Voelklingen

Hi,

I've submitted a patch some time ago, which enables the user to set the
role within the connection string. It enables applications, which don't
have the knowledge of PostgreSQL-roles or "fine-tuning-mechanisms", to
use roles.

Has anyone reviewed this patch?


bye
Chris

On Wed, 5 Aug 2009, JUNG, Christian wrote:

> here's a small patch to set the role at connection time (parameter
> "role"). The patch was made against the current CVS-version.
>

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.

2) It doesn't have Datasource support.  Any option that can be set via the
URL should also be settable on a Datasource.

3) In the past people have asked to be able to set other GUC parameters
(search_path, optimizer hints, ...) and we've resisted because we didn't
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.

Kris Jurka

> -----Original Message-----
> From: Kris Jurka [mailto:books@ejurka.com]
> Sent: Wednesday, September 02, 2009 6:30 PM
> To: JUNG, Christian
> Cc: pgsql-jdbc@postgresql.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

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