#25476: bug in array handling hit in get_constraints() for psycopg2?
-------------------------------------+-------------------------------------
Reporter: heasus | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 1.8
(models, ORM) |
Severity: Normal | Resolution:
Keywords: psycopg2 fetchall | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by claudep:
Old description:
> 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.
New description:
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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/25476#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.15b9c43fbe34164cf94750a7cbb2b0b0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.