Re: Insert records in the tavke only if they are not exist

On 12/7/24 15:58, Igor Korot wrote:
> Hi, Adrian,
>

>> What distinguishes your tables from other users' tables?
>
> I am making the tables and naming them with a specific pattern.
>
> Now I'm curious - if I start psql and will want to create a table
> named pg_am, what will happen?
> I presume psql will produce error saying that the system table with
> that name exists and the user can't create ome.
> Am I right?

When you refer to psql are you talking about the CLI program or the
Postgres server in general?

As to table names it depends. A schema is a namespace so if you put the
table in it's own schema then the server will not complain:

create table test_sch.pg_am(id integer);
CREATE TABLE

\d *.pg_am
Table "pg_catalog.pg_am"
Column | Type | Collation | Nullable | Default
-----------+---------+-----------+----------+---------
oid | oid | | not null |
amname | name | | not null |
amhandler | regproc | | not null |
amtype | "char" | | not null |
Indexes:
"pg_am_oid_index" PRIMARY KEY, btree (oid)
"pg_am_name_index" UNIQUE CONSTRAINT, btree (amname)

Table "test_sch.pg_am"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
id | integer | | |

I would strongly advise against this naming schema for the above reason.

>
>>
>>> 4. Program is executed.
>>> 5. User closes the program.
>>> 6.. Later on the user decides that there is a need
>>> for another table (inside psql or any other client)
>>
>> The above is where I started twitching.
>>
>> How do you keep them out of your tables?
>
> My tables are named with the specific pattern.
>
> Also - see above.

Yes, but if you allow users into the database:

a) They can figure out what that pattern is.

b) Mess with the tables.

>
>>
>> How do you get these changes to play nice with the existing structure?
>
> Again - not sure what you mean here....

Examples:

1) A user creates table that creates a FK relationship to one of 'your'
tables and you then change 'your' table and invalidate that relationship.

2) A user changes the structure of 'your' tables.

> If one of my tables will be dropped - it will be re-created.
> I'm using CREATE TABLE IF NOT EXIST.

This means every time the app is run it could potentially run one or
more schema/data migrations.

How are you going to track the state of the database in order to get it
back to what it was when the change or changes occurred?

>
>>
>>
>>> All records that were there are staying unchanged.
>>
>> INSERT/UPDATE against your tables is not a possibility?
>
> It is..
> All I;m saying that when the app starts-up, this is done automatically

Again, using what point in time state?

>
> And if the user decides to insert some data - that's on him

No the point of this thread is it's on you or you would not be asking
how to restore to a known state.

>>
>> This is the part that confuses me.
>>
>> If you are going to allow ad hoc and at will changes how do you know
>> what is actually the correct change?
>
> I don't.
> Think about MS ACCESS-like applications.
> ACCESS creates the internal tables to keep track of some
> internals.
> Is there a possibility of a clash with the user table? Ofc there is.
> But MS is still doing it nevertheless, because chances of this occurring
> are really slim.
> And if a user acquire access to those internal tables and start modify
> them and in the process screw something up, well he uses MS product
> as a developer and so should know better as a developer
> And if MS can do it - why can't I?

Because MS has the lawyers to keep at bay anyone complaining that Access
blew up their application.

>
>
>>
>>>
>>> Now, the creation/population is done inside a transaction.
>>
>> I'm not sure that a transaction is going to solve the issue I raised
>> above, it will just make one thing happen with no guarantee that it is
>> the correct outcome.
>
> What is considered correct outcome is strongly on user if we are talking
> about my app.

Except you are asking how to deal with changes and so you are taking
ownership of them. And in the case you describe, two different instances
of the app making changes, how do you decide which one wins?

>> To me this is the tail wagging the dog. The thought of allowing users to
>> change the database structure and you dealing with it after the fact is
>> just disturbing to me.
>
> But not to me.
> My application targets developers, not end users.

Who are users in your application.

>
> Thank you.
>
>>
>>>
>>>>
>>>>
>>>>>
>>>>> Thank you.
>>
>> --
>> Adrian Klaver
>> adrian(dot)klaver(at)aklaver(dot)com
>>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com