elein <elein@varlena.com> writes:
> This is the repro with the sql file below.
I looked into this, and the answer is you're doing it to yourself;
you shouldn't be explicitly re-specifying the defaults for the child
columns.
> create table answer_numeric (
> avalue numeric
> ) inherits (answer_values) ;
> alter table answer_numeric alter column avid set default nextval('answer_values_avid_seq');
It's unnecessary to have that "alter column set default" command,
because avid will have inherited the default expression from the parent
anyway. The reason that setting it changes pg_dump's output is that
what you are setting is not quite right: the actual default expression
in the parent is
nextval('public.answer_values_avid_seq')
Since that's different, pg_dump concludes that the child's default is
non-inherited and emits a redefinition of the column.
The reason I didn't see the same behavior in CVS tip is that now that
we use regclass literals for nextval() arguments, the changed default
still lists out the same way as the parent's default, and so pg_dump
thinks it's an inherited default.
It strikes me that there is still a risk here, which is that because
listing of regclass values is search-path-sensitive, pg_dump could
come to the wrong conclusion about the inheritance of a default when
the child is in a different schema than the parent. We could probably
fix that by comparing adbin strings instead of the reverse-compiled
expressions to decide if a child default matches its parent or not.
Alternatively, maybe we should add explicit inheritance information
to pg_attrdef. There's already a proposal to do that for constraints...
regards, tom lane
