Opened 6 years ago

Last modified 4 months ago

#23318 assigned New feature

Management command dbshell does not use DATABASE[...]['OPTIONS'] to set env PGOPTIONS

Reported by: benjaoming Owned by: Flavio Curella
Component: Core (Management commands) Version: master
Severity: Normal Keywords:
Cc: tomi.kyostila@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

I am trying to make use of a different "search_path" by use of settings.DATABASE[...]['OPTIONS'] = '-c search_path=my_other_schema,public' -- however, since they are not passed, python manage.py dbshell --database=MY_OTHER_DATABASE_CONNECTION will yield an unexpected result.

The problem is that the shell env variable PGOPTIONS="-c search_path=MY_SEARCH_PATH_CONF" is not set.

I am using it for the purpose of having multiple south_migrationhistory tables, one for every database connection. They should have been populated by:

python manage.py sqlall south | python manage.py dbshell --database=DBNAME

Current work-around:

python manage.py sqlall south | PGOPTIONS="-c search_path=NAME_OF_MY_SCHEMA" python manage.py dbshell --database=DBNAME

I am not sure how 1.7 will handle migration histories when populating different database connections and auto-selecting them using routers. But at least having the above to work would be nice, because it makes it easy to manually pipe around the SQL statements to different DB connections.

Also in more severe cases, not having the connection options passed to dbshell might yield other unexpected results!?

This might be of interest to other db backends, but please limit the issue here to only postgres, as it's perfectly simple to copy in the contents of OPTIONS to the env variable PGOPTIONS.

Change History (9)

comment:1 Changed 6 years ago by Tim Graham

Component: Database layer (models, ORM)Core (Management commands)
Triage Stage: UnreviewedAccepted
Type: BugNew feature

It looks like a reasonable request, and we recently enhanced the options that dbshell accepts when using MySQL (#22646).

comment:2 Changed 6 years ago by Flavio Curella

Owner: changed from nobody to Flavio Curella
Status: newassigned

comment:3 Changed 6 years ago by Flavio Curella

Easy pickings: set
Has patch: set
Version: 1.7-rc-2master

comment:4 Changed 6 years ago by Tim Graham

Easy pickings: unset
Patch needs improvement: set

I left comments for improvement on the PR. Please uncheck "Patch needs improvement" when you update it, thanks.

comment:5 Changed 5 years ago by Tomi Kyöstilä

Cc: tomi.kyostila@… added

comment:7 Changed 4 months ago by Dulmandakh

The implementation differs from initial implementation because OPTIONS may be used to set many connection configurations of psycopg2 other than options or PGOPTIONS.

comment:8 in reply to:  7 ; Changed 4 months ago by felixxm

Replying to Dulmandakh:

.... may be used to set many connection configurations of psycopg2 other than options or PGOPTIONS.

I'm not sure what does it mean? You want to pass options to the PGOPTIONS so how it can support sth else? The list of all available options can be found in the PostgreSQL docs. Also I'm not sure (as pointed by Tim) if passing all possible options is safe.

comment:9 in reply to:  8 Changed 4 months ago by Dulmandakh

Replying to felixxm:

Replying to Dulmandakh:

.... may be used to set many connection configurations of psycopg2 other than options or PGOPTIONS.

I'm not sure what does it mean? You want to pass options to the PGOPTIONS so how it can support sth else? The list of all available options can be found in the PostgreSQL docs. Also I'm not sure (as pointed by Tim) if passing all possible options is safe.

IIRC, OPTIONS passed to psycopg2.connect method directly as a part of kwargs, so it might be best to not interfere with it. Also we cannot determine which options are safe or not, so it might be best to leave it a web developer to decide.

Note: See TracTickets for help on using tickets.
Back to Top