On Tue, 2 Aug 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> 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?
'k, am checking into this ... is it a simple matter of removing that
second record above from pg_depend to "fix" the pg_dump issue, or
something more involved then that?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
