Can Django assume connect privileges to the 'postgres' database?

154 views
Skip to first unread message

Tim Graham

unread,
May 13, 2015, 11:29:49 PM5/13/15
to django-d...@googlegroups.com
Django 1.8 requires a connection to the 'postgres' database in order to resolve ticket #16969 [1]. We've had several reports of cases where connecting to the 'postgres' database isn't permitted (e.g. Heroku and other shared hosting providers) which causes problems when running tests and in some other cases [2]. Is it an invalid assumption that we should be able to access the 'postgres' database, or can we consider it a bug in proper Django setup? The original assumption that 'postgres' should always be accessible was based on my reading of the PostgreSQL docs: "The postgres database is a default database meant for use by users, utilities and third party applications" [3].

[1] https://code.djangoproject.com/ticket/16969
[2] https://code.djangoproject.com/ticket/24791
[3] http://www.postgresql.org/docs/9.1/interactive/app-initdb.html

Carl Meyer

unread,
May 14, 2015, 12:22:58 PM5/14/15
to django-d...@googlegroups.com
Hi Tim,

On 05/13/2015 09:29 PM, Tim Graham wrote:
> Django 1.8 requires a connection to the 'postgres' database in order to
> resolve ticket #16969 [1]. We've had several reports of cases where
> connecting to the 'postgres' database isn't permitted (e.g. Heroku and
> other shared hosting providers) which causes problems when running tests
> and in some other cases [2]. Is it an invalid assumption that we should
> be able to access the 'postgres' database, or can we consider it a bug
> in proper Django setup? The original assumption that 'postgres' should
> always be accessible was based on my reading of the PostgreSQL docs:
> "The postgres database is a default database meant for use by users,
> utilities and third party applications" [3].

It seems clear that in practice connect privileges to the 'postgres'
database are not always available, and I don't believe the quoted
sentence from the Postgres docs is clear enough to provide strong
justification for filing bugs against providers who don't make it
available. If I were such a provider, I certainly would not read that
sentence as a mandate, especially given that for most single-database
use cases there's no need to be able to connect to the 'postgres' database.

I think the answer here is appropriate configurability. I see at least
two ways to make that happen:

1) add a config OPTION to set what database is used when establishing a
"no-database" connection? The option would default to 'postgres', but
people who need to run tests against a provider who doesn't allow
connections to 'postgres' could set it to something else.

2) Make it possible to specify an already-existing database to use for
running the tests, in such a way that Django won't try to create one or
tear it down, and thus won't need a no-db connection at all.

Carl
> --
> You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-develop...@googlegroups.com
> <mailto:django-develop...@googlegroups.com>.
> To post to this group, send email to django-d...@googlegroups.com
> <mailto:django-d...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/275e62bd-efc6-4252-8f7b-0136b7011753%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/275e62bd-efc6-4252-8f7b-0136b7011753%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

signature.asc

Claude Paroz

unread,
May 14, 2015, 2:42:25 PM5/14/15
to django-d...@googlegroups.com
Le jeudi 14 mai 2015 18:22:58 UTC+2, Carl Meyer a écrit :
(...)


I think the answer here is appropriate configurability. I see at least
two ways to make that happen:

1) add a config OPTION to set what database is used when establishing a
"no-database" connection? The option would default to 'postgres', but
people who need to run tests against a provider who doesn't allow
connections to 'postgres' could set it to something else.

2) Make it possible to specify an already-existing database to use for
running the tests, in such a way that Django won't try to create one or
tear it down, and thus won't need a no-db connection at all.

Carl

Hi Carl,
I tried and proposed a patch with a third approach [1]: test the 'postgres' connection, catch database errors and fallback to the default database when the connection fails.
I guess that when no access is granted to the 'postgres' database, it's most probably that the user has only access to one database.
It wouldn't cost much to provide for an additional settings key, though, if needed.

Claude

[1] https://github.com/django/django/pull/4660

Carl Meyer

unread,
May 14, 2015, 3:33:54 PM5/14/15
to django-d...@googlegroups.com
Hi Claude,
That approach makes sense to me! I also don't see any use cases for
options other than 'postgres' or 'main db', so just making it a simple
fallback with warning seems reasonable enough.

Carl

signature.asc
Reply all
Reply to author
Forward
0 new messages