pg_service.conf support

[valczir.darkvein@…]

In PostgreSQL, there is a config file, pg_service.conf, that allows one to define shortcut names to connection parameters. This makes it easy to migrate a database without having to mess with individual application configurations - just change the pg_service.conf file and you're done.

I've managed to get it working, although I'm not sure this is the right way to do it. Unfortunately, as far as I know, psycopg2 only supports a service name in a dsn string, not as a connection param, so I've had to run a completely separate connect() for pg_service. However, as a service name in pg_service.conf defines all of the other connection options, I don't think it's a large problem; it just bothers me that they need to be separate.

I'm also not sure how best to handle the case where there is a service name and also normal db connection params. On my side, since we're using pg_service for nearly everything, I've just got it ignoring normal connection params if a service name exists.

Anyway, a diff between my a/base.py and b/base.py (a being the original django/db/backends/postgresql_psycopg2 directory, b being the copy of a where I was doing my changes) is attached, more to show what I did than as a suggested patch - this was just a quick hack thrown together to get things working for me. The version of django I was editing was 1.2.4, I believe (python26 manage.py --version shows 1.2.4, at least). I've tested both with a service and with the original connection params, and it seems to work.

[valczir.darkvein@…]

Example patch to django/db/backends/postgresql_psycopg2/base.py to get pg_service working

[Russell Keith-Magee]

I'm not sure I see the benefit here. It's certainly nice that Postgres provides a way to perform the abstraction that you describe, but I'm not sure I see the advantage that is gained by having Django support it. It would be a configuration scheme that only works for Postgres -- no other backend (that I'm aware of) has an analogous configuration scheme. This means that the cross-database nature of Django would be somewhat compromised -- we would have a DATABASES setting that only works for Postgres.

Closing wontfix; please start a discussion on django-dev if you feel strongly about this.