Opened 9 years ago
Last modified 8 years ago
#25476 closed Cleanup/optimization
bug in array handling hit in get_constraints() for psycopg2? — at Version 3
Reported by: | heasus | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | psycopg2 fetchall inspectdb permissions |
Cc: | gagangupt16@…, marcos@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Using inspectdb of Django1.8.4 with psycopg2 2.6.1 to import an existing db, get_constraints() attempts to read table constraints. It exits here parsing foreign keys with the traceback:
File "/home/www/db/lib/python3.4/site-packages/django/db/backends/postgresql_psycopg2/introspection.py", line 171, in get_constraints "foreign_key": tuple(used_cols[0].split(".", 1)) if kind.lower() == "foreign key" else None, IndexError: list index out of range
The array of columns returned from the db is populated:
SELECT kc.constraint_name, kc.column_name, c.constraint_type, array(SELECT table_name::text || '.' || column_name::text FROM information_schema.constraint_column_usage WHERE constraint_name = kc.constraint_name) FROM information_schema.key_column_usage AS kc JOIN information_schema.table_constraints AS c ON kc.table_schema = c.table_schema AND kc.table_name = c.table_name AND kc.constraint_name = c.constraint_name WHERE kc.table_schema = 'public' AND kc.table_name = 'things' ORDER BY kc.ordinal_position ASC;
constraint_name | column_name | constraint_type | array ------------------------+-------------+-----------------+----------------------- things_pkey | trunk | PRIMARY KEY | {things.trunk,things.c hild} things_child_fkey | child | FOREIGN KEY | {children.idx} things_trunk_fkey | trunk | FOREIGN KEY | {children.idx} things_pkey | child | PRIMARY KEY | {things.trunk,things.c hild}
but empty from cursor.fetchall(): for constraint, column, kind, used_cols in cursor.fetchall(). A script using psycopg2 directly does not exhibit this problem. I;ve also tried a current development checkout of django.
This is as far as I've traced this so far and it does not seem to be a known issue.
Change History (3)
comment:1 by , 9 years ago
Component: | Uncategorized → Database layer (models, ORM) |
---|
comment:2 by , 9 years ago
Type: | Uncategorized → Bug |
---|
comment:3 by , 9 years ago
Description: | modified (diff) |
---|