Subject: Re: Duplicate Key Values

From: mark bradley <[email-masked]>
Date: Tue, 11 Mar 2025 14:28:55 +0000

An "interesting" effect of reindexing is that all the records that were dups in the nodes table were deleted, both copies.

Also, all rows having node_id as a foreign key in other tables were deleted, which means all rows in these tables were deleted.

Fortunately these are not huge tables.  I will reenter the data, make a backup, and then try your further extended suggestions.

Best regards,
Mark Brady
amazon.com/author/markjbrady<https://amazon.com/author/markjbrady>
________________________________
From: Adrian Klaver <[email-masked]>
Sent: Friday, March 7, 2025 3:25 PM
To: mark bradley <[email-masked]>
Cc: pgsql-general <[email-masked]>
Subject: Re: Duplicate Key Values

On 3/7/25 11:47, mark bradley wrote:
> Wouldn't that be nice 🙂

No, because you would end up with a mess.

My AI rant:

AI is neither artificial or intelligent. It is human code that pattern
matches and then throws the matches against the wall and hope something
sticks. It is left to the human to clean up.

At any rate, in this post:

https://www.postgresql.org/message-id/75b33741-ee99-4524-b63a-edad21c1266d%40aklaver.com

You where provided an answer, which is further extended here:

https://www.postgresql.org/message-id/CAKAnmm%2BBBBaXGN2xPHhXywkwb72UWzinWu2wQ5WadcMw3_57rQ%40mail.gmail.com

>
>
> Best regards,
> Mark Brady
> _amazon.com/author/markjbrady <https://amazon.com/author/markjbrady>_
> ------------------------------------------------------------------------
> *From:* Adrian Klaver <[email-masked]>
> *Sent:* Friday, March 7, 2025 10:55 AM
> *To:* mark bradley <[email-masked]>
> *Cc:* pgsql-general <[email-masked]>
> *Subject:* Re: Duplicate Key Values
> On 3/7/25 06:34, mark bradley wrote:
>> This is what MS Copilot has to say about this apparent bug where
>> Postgres inserts extra rows violating a primary keys uniqueness constraint:
>
>
>
>> What to do?  I hesitate to just delete my tables and start over because
>> this error will reoccur.
>
> Let the AI solve it.
>
>>
>> Best regards,
>> Mark Brady
>
>
> --
> Adrian Klaver
> [email-masked]
>

--
Adrian Klaver
[email-masked]

---

From: Greg Sabino Mullane <[email-masked]>
Date: Tue, 11 Mar 2025 10:33:22 -0400

On Tue, Mar 11, 2025 at 10:29 AM mark bradley <[email-masked]>
wrote:

> An "interesting" effect of reindexing is that all the records that were
> dups in the nodes table were deleted, both copies.
>

Er...that's not just interesting, but alarming - if true. Can you show the
steps you took?

Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support

---

From: Ron Johnson <[email-masked]>
Date: Tue, 11 Mar 2025 10:40:11 -0400

Do you *currently* take regular backups?

We'd be glad to show you how to take regular logical backups.

On Tue, Mar 11, 2025 at 10:29 AM mark bradley <[email-masked]>
wrote:

> Also, all rows having node_id as a foreign key in other tables were
> deleted, which means all rows in these tables were deleted.
>
> Fortunately these are not huge tables.  I will reenter the data, make a
> backup, and then try your further extended suggestions.
>
> Best regards,
> Mark Brady
> *amazon.com/author/markjbrady <https://amazon.com/author/markjbrady>*
> ------------------------------
> *Sent:* Friday, March 7, 2025 3:25 PM

-- 
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

---

From: Adrian Klaver <[email-masked]>
Date: Tue, 11 Mar 2025 07:56:54 -0700

> dups in the nodes table were deleted, both copies.

I am trying to understand above.

Was there at least one row of each node_id left?

---

From: mark bradley <[email-masked]>
Date: Tue, 11 Mar 2025 15:05:12 +0000

The rows that were preserved in the nodes table were the ones that were not dups originally.

Best regards,
Mark Brady
Sent: Tuesday, March 11, 2025 10:56 AM

---

From: Adrian Klaver <[email-masked]>
Date: Tue, 11 Mar 2025 08:12:40 -0700

> The rows that were preserved in the nodes table were the ones that were 

1) To be specific:

a) If there where two or more rows with a node_id, after the reindexing 
was there only one left?

b) Or for any node_ids that where duplicated did reindexing eliminate 
all rows with that node_id.

2) Per post from Greg Sabino Mullane, you need to show us the steps you 
took to reindex the table.

> *Sent:* Tuesday, March 11, 2025 10:56 AM
>> _amazon.com/author/markjbrady <https://amazon.com/author/markjbrady 
> <https://amazon.com/author/markjbrady>>_
> 
> 
> -- 
> Adrian Klaver

---

From: mark bradley <[email-masked]>
Date: Tue, 11 Mar 2025 15:16:52 +0000

b

REINDEX TABLE node;

Also reindexed table with node_id as a foreign key in the same way.

Best regards,
Mark Brady
Sent: Tuesday, March 11, 2025 11:12 AM

1) To be specific:

---

From: Greg Sabino Mullane <[email-masked]>
Date: Tue, 11 Mar 2025 11:52:14 -0400

A reindex is not going to remove rows from the table, so we need to see how
you came to the conclusion that it did.

Cheers,
Greg

---

From: Adrian Klaver <[email-masked]>
Date: Tue, 11 Mar 2025 09:00:27 -0700

On 3/11/25 08:16, mark bradley wrote:

A)
   1) Please do not top post. Either inline or bottom post. It makes 
things like the below easier to follow. I wrote the post you responded 

B)
  From a previous post of yours:

"
1.
Originally, the key in the node table was a sequence, but I changed it 
to a non-sequence.

2.
There is no index on the primary key node_id, and I understand there 
should be one.

3.
I didn't explicitly use Postgres inheritance but there are two tables 
that are subclasses of node.  There are dataset nodes and 
processing_node [s] tables.  Each is a type of node and have primary 
keys that are foreign keys from the node table.  This key is node_id.
"

As to point 2, from this message:

there is an index on node_id as it is the Primary Key.

Why do you think there is not?

Can you elaborate more on point 3.

Are you calling the Foreign Key relationships subclassing?

C)

 > Also reindexed table with node_id as a foreign key in the same way.

Is there anything in Postgres log at the time you did the above that 
showed it did more then a REINDEX?

> *Sent:* Tuesday, March 11, 2025 11:12 AM
>> <https://amazon.com/author/markjbrady 
> <https://amazon.com/author/markjbrady>>>_
>> 
>> 
>> -- 
>> Adrian Klaver

---

From: mark bradley <[email-masked]>
Date: Tue, 11 Mar 2025 18:52:29 +0000

Why do you think there is not?
My mistake, I misread the output from \d dataset

Although I did not explicitly use Postgres to declare inheritance, logically speaking table dataset and processing _node inherit or are subclasses of node because they are subclasses of node in a dataflow diagram.

In terms of keys, this is accomplished by having the node_id key in the node table appear as a foreign key and as a primary key in both the dataset and processing_node tables.

Not that I can tell.

Best regards,
Mark Brady
Sent: Tuesday, March 11, 2025 12:00 PM

A)

B)

"
1.

2.

3.

C)

---

From: Adrian Klaver <[email-masked]>
Date: Tue, 11 Mar 2025 12:37:41 -0700

On 3/11/25 11:52, mark bradley wrote:
> Although I did not explicitly use Postgres to declare inheritance, 
> logically speaking table /dataset/ and /processing _node/ inherit or are 
> subclasses of /node/ because they are subclasses of /node/ in a dataflow 
> diagram.
> 
> 
> In terms of keys, this is accomplished by having the /node_id/ key in 
> the /node/ table appear as a foreign key and as a primary key in both 
> the /dataset/ and /processing_node/ tables.

You will need to show the schema definitions for:

   node
   dataset
   processing_node

Best to do using psql \d <table_name>

Also in from previous \d dataset there where NOT VALID FK definitions.

Did you ever run VALIDATE CONSTRAINT against them?

---

From: mark bradley <[email-masked]>
Date: Tue, 11 Mar 2025 19:55:59 +0000

It happened again.  Now there are no sequences (although there once was).

Sequence of data reentry:

  1.
I reentered the node_ids in table node as a primary key.
  2.
I reentered the datasets, in table dataset.
  3.
Node_id was already a PK in dataset.
  4.
I set node_id to also be a foreign key in dataset.
  5.
I went back to look at node and see that duplicate key values appeared.

Processing nodes are unaffected because I didn't add any data to the processing_node table.

Next, I'm going to create a simple database from scratch and see if I can duplicate this behavior.

Best regards,
Mark Brady
Sent: Tuesday, March 11, 2025 3:37 PM

   node
   dataset
   processing_node

---

From: Adrian Klaver <[email-masked]>
Date: Tue, 11 Mar 2025 13:24:37 -0700

> It happened again.  Now there are no sequences (although there once was).

Read my previous post and provide the information requested.

Also:

1) Postgres version.

2) Where did you get Postgres from?

>     I reentered the /node_id/s in table node as a primary key.
>  2.
>     I reentered the datasets, in table /dataset/.
>  3.
>     /Node_id/ was already a PK in dataset.
>  4.
>     _I set _/_node_id_/_ to also be a foreign key in _/_dataset_/_._
>  5.
>     I went back to look at /node/ and see that duplicate key values
>     appeared.
> 
> 
> 
> 
> Processing nodes are unaffected because I didn't add any data to the 
> /processing_node/ table.
> 
> *Sent:* Tuesday, March 11, 2025 3:37 PM

---

From: Adrian Klaver <[email-masked]>
Date: Wed, 12 Mar 2025 08:46:49 -0700

> Read my previous post and provide the information requested.

Mark sent me the below, which answers some of the questions, namely 
there is inheritance going on:

Universal Metadata Schema=# \d node
Table "public.node"
Column | Type | Collation | Nullable | Default
-----------+-----------+-----------+----------+---------
node_id | integer | | not null |
node_type | node_type | | not null |
Indexes:
"node_pkey" PRIMARY KEY, btree (node_id)
"node_id" UNIQUE CONSTRAINT, btree (node_id) INCLUDE (node_id)
Referenced by:
TABLE "user_role" CONSTRAINT "a" FOREIGN KEY (node_id) REFERENCES 
node(node_i
d) NOT VALID
TABLE "dataset" CONSTRAINT "node_id" FOREIGN KEY (node_id) REFERENCES 
node(no
de_id) NOT VALID
Number of child tables: 2 (Use \d+ to list them.)

Universal Metadata Schema=# \d dataset
Table "public.dataset"
Column | Type | Collation | Nullable | Default
---------------------------+---------------------------+-----------+----------+--
-------
node_id | integer | | not null |
dataset_name | character varying(25) | | not null |
notes | text | | |
dataset_type | database_type | | |
dataset_maturity | database_maturity_type | | |
disposition | disposition_type | | |
start_date | date | | |
end_date | date | | |
most_recent_update | date | | |
update_periodicity | interval | | |
system_of_record | text | | |
point_of_contact | integer | | |
dataset_url | text | | |
classification_level | classification_level_type | | |
physical_location | text | | |
quality_control | yes_no_type | | |
dataset_documentation_url | text | | |
description | text | | |
node_type | node_type | | |
Indexes:
"dataset_pkey" PRIMARY KEY, btree (node_id)
Foreign-key constraints:
"node_id" FOREIGN KEY (node_id) REFERENCES node(node_id) NOT VALID
"poc" FOREIGN KEY (point_of_contact) REFERENCES poc(poc_id) NOT VALID
Referenced by:
TABLE "dataset_table" CONSTRAINT "dataset" FOREIGN KEY (node_id) 
REFERENCES d
ataset(node_id) NOT VALID
TABLE "system_dataset" CONSTRAINT "system_dataset_node_id_fkey" FOREIGN 
KEY (
node_id) REFERENCES dataset(node_id) NOT VALID
Inherits: node

Universal Metadata Schema=# \d processing_node
Table "public.processing_node"
Column | Type | Collation | Nullable | Default
-----------------------+-----------------------+-----------+----------+---------
node_id | integer | | not null |
processing_node_name | character varying(25) | | |
description | text | | |
notes | text | | |
point_of_contact | integer | | not null |
is_a_user_application | yes_no_type | | not null |
node_type | node_type | | |
Indexes:
"processing_node_pkey" PRIMARY KEY, btree (node_id)
Foreign-key constraints:
"processing_node_point_of_contact_fkey" FOREIGN KEY (point_of_contact) 
REFERE
NCES poc(poc_id)
Referenced by:
TABLE "system_processing_node" CONSTRAINT 
"system_processing_node_processing_
node_id_fkey" FOREIGN KEY (processing_node_id) REFERENCES 
processing_node(node_id
) NOT VALID
Inherits: node

Universal Metadata Schema=# ALTER TABLE node VALID
ATE CONSTRAINT node_id;
ERROR: constraint "node_id" of relation "node" is
not a foreign key or check constraint
Universal Metadata Schema=# ALTER TABLE dataset VA
LIDATE CONSTRAINTnode_id;
ERROR: syntax error at or near "CONSTRAINTnode_id
"
LINE 1: ALTER TABLE dataset VALIDATE CONSTRAINTnod
e_id;
^
 > Did you ever run VALIDATE CONSTRAINT against them?
Here is the run

Universal Metadata Schema=# ALTER TABLE node VALID
ATE CONSTRAINT node_id;
ERROR: constraint "node_id" of relation "node" is
not a foreign key or check constraint
Universal Metadata Schema=#

Universal Metadata Schema=# ALTER TABLE dataset VA
LIDATE CONSTRAINT node_id;
ALTER TABLE
Universal Metadata Schema=#

---

From: Adrian Klaver <[email-masked]>
Date: Wed, 12 Mar 2025 09:01:10 -0700

> there is inheritance going on:

Mark, to illustrate:

create table node (node_id integer primary key, fld1 varchar);
create table node_1 (node_id integer primary key, node_1_fld boolean) 
inherits ( node);
NOTICE:  merging column "node_id" with inherited definition

insert into node values (1, 'dog');
insert into node_1 values (1, 'cat', 'f');

select * from node;
  node_id | fld1
---------+------
        1 | dog
        1 | cat

This is explained here:

https://www.postgresql.org/docs/current/sql-createtable.html

INHERITS ( parent_table [, ... ] )

"... , and by default the data of the child table is included in scans 
of the parent(s)."

This explains why you see duplicates of node_id.

Though if you try to enter a duplicate value in to a particular table 
you get:

insert into node_1 values (1, 'test', 't');
ERROR:  duplicate key value violates unique constraint "node_1_pkey"
DETAIL:  Key (node_id)=(1) already exists.

This still does not explain why REINDEX TABLE node; caused data to 
disappear?

>  > Did you ever run VALIDATE CONSTRAINT against them?

As error notes VALIDATE CONSTRAINT only works on FK and check 
constraints. You would need to run against the FK constraints that where 
marked NOT VALID e.g "dataset" on the dataset table.

Honestly, I think you need rework your data model. Not sure what the 
inheritance is getting you. Seems simpler to just have the node table 
not be inherited and just use FK relationships back to it.

---

From: mark bradley <[email-masked]>
Date: Thu, 13 Mar 2025 14:56:01 +0000

> node_id | fld1

That would make sense except that I never explicitly use the inherits option in the node_1 (my dataset) table.  Postgres seems to be assuming that.

Also, the second column in node and in dataset are two different columns.  However, Postgres insists on the node_type attribute being included (last column) in table dataset and won't let me delete it.   This is redundant because every dataset is a dataset type of node.

...
The reason for the current design is that I also have a dataflow table as shown below.

A dataflow record describes the flow of data between two nodes.  Now, if there are 3 types of node: dataset, processing, and user, then there are 9 types of dataflow. Hence, 9 tables are needed to represent the dataflows instead of 1.  In the below,  source_id and destination_id are both node_ids.  If I want to know if a node is a dataset, processing node, or a user, I just look that up in the nodes table.

So, I think the crux of the problem is that Postgres assumes that inheritance is declared when it is not.

More answers to your questions coming.

Best regards,
Mark Brady

Sent: Wednesday, March 12, 2025 12:01 PM

Mark, to illustrate:

select * from node;
  node_id | fld1
---------+------
        1 | dog
        1 | cat

This is explained here:

---

From: Ron Johnson <[email-masked]>
Date: Thu, 13 Mar 2025 11:05:45 -0400

Postgresql does not assume / default to inheritance.  In text-mode clients
where you type in "raw" SQL, you have to explicitly add an explicit
"INHERITS <parent_table>" clause to the "CREATE TABLE foo"  statement.

Are you creating the tables via PgAdmin point-and-click?

On Thu, Mar 13, 2025 at 10:56 AM mark bradley <[email-masked]>
wrote:

> That would make sense except that I never explicitly use the *inherits* option
> in the *node_1* (my *dataset*) table.  Postgres seems to be assuming
> that.
>
> Also, the second column in *node* and in *dataset* are two different
> columns.  However, Postgres insists on the *node_type* attribute being
> included (last column) in table *dataset *and won't let me delete it.   This
> is redundant because every dataset is a dataset type of node.
>
> ...
> The reason for the current design is that I also have a *dataflow* table
> as shown below.
>
> A dataflow record describes the flow of data between two nodes.  Now, if
> there are 3 types of node: dataset, processing, and user, then there are 9
> types of dataflow. Hence, 9 tables are needed to represent the dataflows
> instead of 1.  In the below,  *source_id* and *destination_id* are both
> *node_id*s.  If I want to know if a node is a dataset, processing node,
> or a user, I just look that up in the nodes table.
>
>
> *Sent:* Wednesday, March 12, 2025 12:01 PM

---

From: Adrian Klaver <[email-masked]>
Date: Thu, 13 Mar 2025 08:23:04 -0700

On 3/13/25 07:56, mark bradley wrote:
>   > node_id | fld1
> That would make sense except that I never explicitly use the 
> *inherits* option in the *node_1* (my *dataset*) table.  Postgres seems 
> to be assuming that.

1) Well it is there from \d node:

and from \d dataset and \d  processing_node

Inherits: node

Also it explains the behavior.

2) Postgres does not assume that, it was done explicitly by some command.

> included (last column) in table *dataset *and won't let me delete 
> it.**This is redundant because every dataset is a dataset type of node.

That is what inheritance does:

"
     The optional INHERITS clause specifies a list of tables from which 
the new table automatically inherits all columns. Parent tables can be 
plain tables or foreign tables.

     Use of INHERITS creates a persistent relationship between the new 
child table and its parent table(s). Schema modifications to the 
parent(s) normally propagate to children as well, and by default the 
data of the child table is included in scans of the parent(s).

     If the same column name exists in more than one parent table, an 
error is reported unless the data types of the columns match in each of 
the parent tables. If there is no conflict, then the duplicate columns 
are merged to form a single column in the new table. If the column name 
list of the new table contains a column name that is also inherited, the 
data type must likewise match the inherited column(s), and the column 
definitions are merged into one. If the new table explicitly specifies a 
default value for the column, this default overrides any defaults from 
inherited declarations of the column. Otherwise, any parents that 
specify default values for the column must all specify the same default, 
or an error will be reported.

     CHECK constraints are merged in essentially the same way as 
columns: if multiple parent tables and/or the new table definition 
contain identically-named CHECK constraints, these constraints must all 
have the same check expression, or an error will be reported. 
Constraints having the same name and expression will be merged into one 
copy. A constraint marked NO INHERIT in a parent will not be considered. 
Notice that an unnamed CHECK constraint in the new table will never be 
merged, since a unique name will always be chosen for it.

     Column STORAGE settings are also copied from parent tables.

     If a column in the parent table is an identity column, that 
property is not inherited. A column in the child table can be declared 
identity column if desired.
"

> inheritance is declared when it is not.

No it does not, as the screenshot shows. There is an explicit setting 
for 'Inherited from table(s)'

---

From: Adrian Klaver <[email-masked]>
Date: Thu, 13 Mar 2025 08:29:27 -0700

> inheritance is declared when it is not.

Follow up.

 From pgAdmin end:

https://www.pgadmin.org/docs/pgadmin4/9.1/table_dialog.html

"Use the drop-down listbox next to Inherited from table(s) to specify 
any parent table(s); the table will inherit columns from the selected 
parent table(s)."

This is an explicit action.

---

From: mark bradley <[email-masked]>
Date: Thu, 13 Mar 2025 15:56:21 +0000

>Postgresql does not assume / default to inheritance.  In text-mode clients where you type >in "raw" SQL, you have to explicitly add an explicit "INHERITS <parent_table>" clause to the >"CREATE TABLE foo"  statement.

>Are you creating the tables via PgAdmin point-and-click?

I am using PgAdmin 4 v9.1.

I think the problem may also be related to the fact that I had node_id and node_type were in both tables from an earlier design and Postgres would not let me delete node_type from the dataset table.

As an experiment, I created a simple version of the same tables from scratch without node_type in the dataset table.  So far, no dups are appearing.

Best regards,
Mark Brady
amazon.com/author/markjbrady<https://amazon.com/author/markjbrady>
________________________________
From: Ron Johnson <[email-masked]>
Sent: Thursday, March 13, 2025 11:05 AM
To: pgsql-general <[email-masked]>
Subject: Re: Duplicate Key Values

Postgresql does not assume / default to inheritance.  In text-mode clients where you type in "raw" SQL, you have to explicitly add an explicit "INHERITS <parent_table>" clause to the "CREATE TABLE foo"  statement.

...

Best regards,
Mark Brady

________________________________
From: Adrian Klaver <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 12, 2025 12:01 PM
To: mark bradley <[email-masked]<mailto:[email-masked]>>
Cc: pgsql-general <[email-masked]<mailto:[email-masked]>>
Subject: Re: Duplicate Key Values

Mark, to illustrate:

select * from node;
  node_id | fld1
---------+------
        1 | dog
        1 | cat

This is explained here:

--
Adrian Klaver
[email-masked]<mailto:[email-masked]>

---

From: Adrian Klaver <[email-masked]>
Date: Thu, 13 Mar 2025 09:05:37 -0700

On 3/13/25 08:56, mark bradley wrote:
>  >Postgresql does not assume / default to inheritance.  In text-mode 
> clients where you type >in "raw" SQL, you have to explicitly add an 
> explicit "INHERITS <parent_table>" clause to the >"CREATE TABLE foo"  
> statement.
> 
> I think the problem may also be related to the fact that I had 
> *node_id* and *node_type *were in both tables from an earlier design and 
> Postgres would not let me delete* node_type* from the* dataset* table.

Because it was inherited:

alter table node_1 drop column fld1;
ERROR:  cannot drop inherited column "fld1"

> 
> As an experiment, I created a simple version of the same tables from 
> scratch without *node_type* in the *dataset* table.  So far, no dups are 
> appearing.

I'm assuming that by 'simple version' you mean no inheritance.

---

From: mark bradley <[email-masked]>
Date: Thu, 13 Mar 2025 16:25:32 +0000

> I'm assuming that by 'simple version' you mean no inheritance.

Inheritance was not specified by me in either case.  By simple, I mean that I used fewer columns in the test version, like so:

Where node_id is a foreign key in dataset, and node_type is not.

Best regards,
Mark Brady
amazon.com/author/markjbrady<https://amazon.com/author/markjbrady>
________________________________
From: Adrian Klaver <[email-masked]>
Sent: Thursday, March 13, 2025 12:05 PM
To: mark bradley <[email-masked]>; Ron Johnson <[email-masked]>; pgsql-general <[email-masked]>
Subject: Re: Duplicate Key Values

---

From: mark bradley <[email-masked]>
Date: Thu, 13 Mar 2025 16:35:03 +0000

>  I'm assuming that by 'simple version' you mean no inheritance.

Anyway, inheritance can be undone via

ALTER TABLE dataset NO INHERIT node;

Now, there are no dups and hopefully it will stay that way.

Best regards,
Mark Brady

---

From: Adrian Klaver <[email-masked]>
Date: Thu, 13 Mar 2025 10:03:55 -0700

On 3/13/25 09:25, mark bradley wrote:
> Inheritance was not specified by me in either case.  By simple, I mean 

Unless someone else is working on this code, it was done by you.

Pretty sure it had to do with from this message:

https://www.postgresql.org/message-id/SJ2PR22MB4328CEB1B47FC1AC4A996CB3BAD12%40SJ2PR22MB4328.namprd22.prod.outlook.com

"Although I did not explicitly use Postgres to declare inheritance, 
logically speaking table dataset and processing _node inherit or are 
subclasses of node because they are subclasses of node in a dataflow 
diagram."

I'm guessing you actually did do the subclassing(inheritance) as it was 
an option presented in the pgAdmin4 CREATE TABLE screen.

Anyway at this point the problem has been identified and a solution devised.

> that I used fewer columns in the test version, like so:
> 
> 
> 
> Where *node_id* is a foreign key in dataset, and *node_type* is not.
> 
> Best regards,
> Mark Brady

---

From: mark bradley <[email-masked]>
Date: Fri, 14 Mar 2025 12:10:21 +0000

Adrian & Ron,

Thank you for your assistance.

Best regards,
Mark Brady
Sent: Thursday, March 13, 2025 1:03 PM