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 Claude Paroz)

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 heasus, 9 years ago

Component: UncategorizedDatabase layer (models, ORM)

comment:2 by heasus, 9 years ago

Type: UncategorizedBug

comment:3 by Claude Paroz, 9 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.
Back to Top