Tom Lane wrote:
Thank you very much for your quick reply. I wanted to do some testing
before reporting back.
> "Jan-Peter Seifert" <jan-peter.seifert@gmx.de> writes:
>> there's a problem with renaming sequences in our databases.
>
> I don't think there's really a problem here. You've apparently got some
> obsolete syntax in your CREATE commands:
>
>> id integer NOT NULL DEFAULT nextval(('public.t2_id_seq'::text)::regclass)
>
> This specifically says that 'public.t2_id_seq' is a string (text) constant,
> which is not going to change in response to anything. If you would
> like it to track renamings of the sequence then it needs to be a
> regclass constant:
>
> id integer NOT NULL DEFAULT nextval('public.t2_id_seq'::regclass)
At first I thought the reason why a renamed sequence couldn't be found
via nextval anymore - even with 'owned by' set - was evaluating the
'historical' adsrc and not the adbin column in pg_attrdef within the
maintenance script. But then I saw the difference in nextval syntax
etc.. The update tool in question uses the obsolete syntax. Has this
text constant thing been official syntax for some time? I wonder why the
person implementing this syntax into the tool did it in the first place.
Now after changing the nextval syntax with an ALTER TABLE as well all
seems to be alright again. Even pgAdmin III now shows 'serial' as data
type for the column again.
> Also, neither of these forms will by itself establish an OWNED BY
> relationship --- you'll need a separate ALTER SEQUENCE OWNED BY
> command if you want that.
Thank you very much for pointing this out. We only discovered it after
looking through a dump some time ago.
Peter Seifert
