inconsistent behavior of nullable with PrimaryKeyConstraint

[Mike Bayer]

this is fairly egregious, breaks alembic as one might expect

from sqlalchemy import *

m = MetaData()

t1 = Table('t1', m, Column('x', Integer), PrimaryKeyConstraint('x'))

t2 = Table('t2', m, Column('x', Integer, primary_key=True))

assert list(t1.primary_key) == [t1.c.x]

assert list(t2.primary_key) == [t2.c.x]

assert t1.c.x.primary_key
assert t2.c.x.primary_key

assert not t2.c.x.nullable
assert not t1.c.x.nullable

[Mike Bayer]

see also https://bitbucket.org/zzzeek/alembic/issue/199/alembic-attempts-to-alter_columns-in-table where we'll try to work around this on that end as well so that this doesn't need an 0.8 backport

[Mike Bayer]

• The :paramref:.Column.nullable flag is implicitly set to False when that :class:.Column is referred to in an explicit :class:.PrimaryKeyConstraint for that table. This behavior now matches that of when the :class:.Column itself has the :paramref:.Column.primary_key flag set to True, which is intended to be an exactly equivalent case. fixes #3023

→ <<cset bd56485f4c15>>

[Mike Bayer]

• The :paramref:.Column.nullable flag is implicitly set to False when that :class:.Column is referred to in an explicit :class:.PrimaryKeyConstraint for that table. This behavior now matches that of when the :class:.Column itself has the :paramref:.Column.primary_key flag set to True, which is intended to be an exactly equivalent case. fixes #3023

→ <<cset ca99fca50d2c>>