On 2019-Jul-12, Tom Lane wrote:
> The OP already found the best method to get out of this, which is to
> drop and re-add the FK constraint. Adding the constraint will force
> a full verification scan, which is what you need here since there's
> no information available about which checks were mis
Yeah, I understood, I have to do that, drop and re-add constraint to avoid
issues.
Adrian Klaver writes:
> On 7/12/19 7:04 AM, Tom Lane wrote:
>> Well, yeah, DISABLE TRIGGER ALL defeats enforcement of FK constraints.
>> That's why you have to be superuser to use it[1].
> The OP is probably trying to understand why the below happens:
> alter table a add constraint a_id_b_fkey f
On 7/12/19 7:04 AM, Tom Lane wrote:
=?UTF-8?Q?Emanuel_Ara=C3=BAjo?= writes:
This is a situation when we needed fill a new store data in a family env.
When I run "alter table a disable trigger all;" ... the foreign key
"a_id_b_fkey" was disabled to, its ok, but I needed run a load data into
tabl
=?UTF-8?Q?Emanuel_Ara=C3=BAjo?= writes:
> This is a situation when we needed fill a new store data in a family env.
> When I run "alter table a disable trigger all;" ... the foreign key
> "a_id_b_fkey" was disabled to, its ok, but I needed run a load data into
> tables "a"and "b" and table a exist
This is a situation when we needed fill a new store data in a family env.
When I run "alter table a disable trigger all;" ... the foreign key
"a_id_b_fkey" was disabled to, its ok, but I needed run a load data into
tables "a"and "b" and table a exists a tuple that not exists in column id_b
-> (ref
