Re: [8.0.3] Not dumping all sequences ... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [8.0.3] Not dumping all sequences ...
Date
Msg-id 25123.1123022212@sss.pgh.pa.us
Whole thread Raw
In response to Re: [8.0.3] Not dumping all sequences ...  ("Marc G. Fournier" <scrappy@postgresql.org>)
Responses Re: [8.0.3] Not dumping all sequences ...  ("Marc G. Fournier" <scrappy@postgresql.org>)
List pgsql-hackers
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Tue, 2 Aug 2005, Tom Lane wrote:
>> Hmm, odd.  But maybe there are traces of a SERIAL linkage?  What do
>> you get from
>> 
>> select * from pg_depend where objid = 'xa_url_id_seq'::regclass;

> # select * from pg_depend where objid = 'xa_url_id_seq'::regclass;
>   classid | objid  | objsubid | refclassid | refobjid | refobjsubid | deptype
> ---------+--------+----------+------------+----------+-------------+---------
>      1259 | 335539 |        0 |      16672 |     2200 |           0 | n
>      1259 | 335539 |        0 |       1259 |   335541 |           1 | i
> (2 rows)

Well, that second line is *definitely* a SERIAL column linkage.

> 'k, checking the docs ... deptype == i is an INTERNAL, and refobjid is 
> what is referencing it (in this case, xa_url, as I'd expect) ... but, 
> looking at \d for xa_url, I'm not seeing anything there to cause it ... no 
> serial values ... the only 'default nextval()' I can find in the schema 
> is something totally unrelated ...

Is it possible they did "create table xa_url(id bigserial, ...)" and
then later changed the default expression for the column?
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: [8.0.3] Not dumping all sequences ...
Next
From: Jeff Davis
Date:
Subject: Re: #escape_string_warning = off