Re: BUG #4582: Renaming sequences and default value

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan-Peter Seifert <Jan-Peter(dot)Seifert(at)gmx(dot)de>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4582: Renaming sequences and default value
Date: 2008-12-17 00:55:31
Message-ID: 18376.1229475331@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Jan-Peter Seifert <Jan-Peter(dot)Seifert(at)gmx(dot)de> writes:
> Tom Lane wrote:
>> 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)

> ... 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.

It might not be entirely the tool's fault. If you had something like
DEFAULT nextval('public.t2_id_seq') in an old version of PG (pre 8.1
I think) then the business with text is actually the most precise, if
not the most useful, translation of that --- pre 8.1 didn't have any way
to track renamings of a serial sequence and so this structure mimics its
semantics. So you might have got to this state via a dump and reload.
Or maybe whoever wrote the tool copied what he saw in an old dump,
without realizing that it wasn't very desirable.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Miroslav Nachev 2008-12-17 07:30:18 BUG #4586: Supporting of Binary instead Bytea for Primary Keys
Previous Message Tom Lane 2008-12-16 22:22:02 Re: BUG #4585: out parameter name cuases disruption in custom aggregate?