What have I done!?!?!? :-) - Mailing list pgsql-general

From Perry Smith
Subject What have I done!?!?!? :-)
Date
Msg-id E2D1EB02-6391-4698-B703-3B02E5271FBC@easesoftware.com
Whole thread Raw
Responses Re: What have I done!?!?!? :-)
Re: What have I done!?!?!? :-)
Re: What have I done!?!?!? :-)
List pgsql-general
Rather than explain how I got here, I’ll just explain the state I’m in.

From psql:

files_development=# \d files
                                          Table "public.files"
   Column   |              Type              | Collation | Nullable |              Default              
------------+--------------------------------+-----------+----------+-----------------------------------
 id         | bigint                         |           | not null | nextval('files_id_seq'::regclass)
 basename   | character varying              |           | not null | 
 parent_id  | bigint                         |           | not null | 
 dev        | bigint                         |           | not null | 
 ftype      | character varying              |           | not null | 
 uid        | bigint                         |           | not null | 
 gid        | bigint                         |           | not null | 
 ino        | bigint                         |           | not null | 
 mode       | bigint                         |           | not null | 
 mtime      | time without time zone         |           | not null | 
 nlink      | bigint                         |           | not null | 
 size       | bigint                         |           | not null | 
 created_at | timestamp(6) without time zone |           | not null | 
 updated_at | timestamp(6) without time zone |           | not null | 
Indexes:
    "files_pkey" PRIMARY KEY, btree (id)
    "index_files_on_parent_id" btree (parent_id)
Foreign-key constraints:
    "fk_rails_15605042e6" FOREIGN KEY (parent_id) REFERENCES files(id)
Referenced by:
    TABLE "files" CONSTRAINT "fk_rails_15605042e6" FOREIGN KEY (parent_id) REFERENCES files(id)

Notice that parent_id is suppose to refer to an id in the same table — at least, that is what I’m trying to do.  I’m trying to create a “root” entry whose parent points to themselves and I botched the code first time around and now I have this:

files_development=# select * from files;
 id | basename | parent_id |    dev    |   ftype   | uid  | gid  | ino | mode  |     mtime      | nlink | size |         created_at         |         updated_at         
----+----------+-----------+-----------+-----------+------+------+-----+-------+----------------+-------+------+----------------------------+----------------------------
 11 | pedz     |      1234 | 687931150 | directory | 1000 | 1002 |   2 | 16877 | 18:43:29.65271 |    31 |   34 | 2022-04-06 21:58:43.570539 | 2022-04-06 21:58:43.570539
 12 | pedz     |        12 | 687931150 | directory | 1000 | 1002 |   2 | 16877 | 18:43:29.65271 |    31 |   34 | 2022-04-06 22:00:29.087417 | 2022-04-06 22:00:29.115021
(2 rows)


The record with id 11 has a parent id of 1234 which doesn’t exist.

My question isn’t how do I fix it, my question is why didn’t Postgres back out the botched record?  Why isn’t it complaining?

I’m using Active Record with the psql adapter.  It has a disable_referential_integrity which takes a block of code.  When the block of code exists, the constraints are put back.  At least, that is what I thought.

I’m wondering if the disabled constraints are still disabled somehow.  If so, how would I check for that and how would I turn them back on?  Or am I way off in the weeds?

Thank you for your time
Perry Smith

Attachment

pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Per-Table vacuum_freeze_min_age
Next
From: Chris Bisnett
Date:
Subject: Re: Per-Table vacuum_freeze_min_age