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