Florian,
Are you certain:
"You can only create an FK if the fields you are referencing in the
foreign table form a PK there. And creating a PK implicitly creates an
index, which you can't drop without dropping the PK :-("
????
I'm not sure I am convinced the necessity of a foreign key, "needing" to
reference a primary keyed entry from a different table.
Florian G. Pflug wrote:
> Wes wrote:
>
>>> You could create the fk-constraints _first_, then disable them, load
>>> the data, reindex, and reenable them afterwards.
>>>
>>> pg_dump/pg_restore can enable and disable fk-constraints before
>>> restoring
>>> the data, I believe. It does so by tweaking the system catalogs.
>>
>>
>> Are referring to '--disable-triggers' on pg_dump? Will this work for
>> foreign key constraints? The doc talks about triggers, but doesn't say
>> anything about FK constraints (are these implemented as triggers?) I
>> don't
>> use pg_restore, just psql.
>
> Yes, I was referring to "--disable-triggers". I always assumes that it
> disables FK-Constraints as well as triggers, but now that you ask I
> realize that I might have never actually tried that ;-)
>
> But FK-Constraints _are_ implemented as triggers internally, so I
> guess it should work.
>
>>> The only problem I can see is that creating the fk-constraints might
>>> create
>>> some indices too. But maybe you can manually drop those indices
>>> afterwards - I
>>> don't know if the fk really _depends_ on the index, or if it creates
>>> it only
>>> for convenience.
>>
>>
>> I don't see any indexes being added to the table beyond what I add, and
>> those added as a primary key constraint. Currently, pg_dump outputs
>> the FK
>> constraints after the indexes are built, as the last steps. If I try
>> to add
>> the FK constraints after loading the database definitions, but
>> without any
>> indexes, I'm not sure what would happen.
>
> Hm.. it i tried it out, and came to the conclusion that my approach
> doesn't work :-(
>
> You can only create an FK if the fields you are referencing in the
> foreign table form a PK there. And creating a PK implicitly creates an
> index, which you can't drop without dropping the PK :-(
>
> So unless you find a way to force postgres to ignore the index when
> inserting data, my suggestion won't work :-(
>
> greetings, Florian Pflug
>
> ---------------------------(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
