>> I am working on a table that does not have a primary key when created. <<
Then, by definition, this was never really a table. You need to do a review of your schema and see the person that did this to you screwed up other things.
What you did post of course is full of all kinds of problems. Your "TB_" is a design flaw called a Tibble in the table name is singular (do you really have only one thing called product? Tables model sets. Therefore their names or collective or plural noun by definition). We have a DATE data type in SQL now and have for several years. Identifiers are never numeric (what math were you going to do on the product_id?), Since columns are all NULL-able, there is no way you can have any kind of key; again, this is by definition.
First, you need alter the table to make the columns not null. My best bet will be you are going to find that you have got nulls for you did not think you had them, so plan on spending some time in scrubbing the data. This will get it up to merely bad 🙁 after that look at your choice of data types. Depending how much scrubbing you have to do, it might be easier to create a properly designed and named table, then move the data over from this imitation deck of punch cards that you got stuck with.
Do you really have a status that is 50 varying characters long? No, probably not. You just grabbed a convenient default size without thinking about it.
But if you do not protect your data, you are going to fill this table up with garbage; someone will put in a status code that is a narrative or a tweet. Do not ask why I know this happens 🙁
You also do not understand there is one and only one display format for dates in ANSI/ISO standard SQL, so you picked an ambiguous local dialect for your data. Since the ISO 8601 format is the second most popular ISO standard on earth after the metric system, this is not very professional
CREATE TABLE Products
(product_gtin CHAR(15) NOT NULL,
product_name VARCHAR (50) NOT NULL, --- careful research or wild stab in the dark?
product_status CHAR (7) DEFAULT 'instore' NOT NULL
CHECK (product_status IN ('instore', 'sold')), -- more codes?
posting_date DEFAULT CURRENT_TIMESTAMP DATE NOT NULL),
PRIMARY KEY (product_gtin, posting_date));
See how a CHECK() constraint and a DEFAULT saves you a lot of programming and guarantees data integrity?
INSERT INTO Products
('1001', 'Toy', 'InStore' , '2017-01-01'),
('1001', 'Toy', 'Sold', '2017-01-02'),
('1002', 'Book', 'InStore', '2017-01-03'),
('1002', 'Book', 'Sold', '2017-01-04');
I will assume you know what a GTIN is or are using some other industry-standard in your actual application. My choice would be to have a pair of (start_date, end_date) that would show the time interval that the product was in a particular status.
Please post DDL and follow ANSI/ISO standards when asking for help.