Is it bad practice not to specify NOT NULL in a SERIAL field? Postgresql

Question

Hello, I was doing some activities and I differed from some colleagues. The end result was the same, but I was wondering if it is bad practice to use the following code

CREATE TABLE Estudio (
    codEst SERIAL PRIMARY KEY,
    nomeEst VARCHAR(25)
);

Instead of what my colleagues used:

CREATE TABLE Estudio (
    codEst SERIAL NOT NULL,
    nomeEst VARCHAR(25),
    
    CONSTRAINT pk_est PRIMARY KEY(codEst)
);

The result, for me, was the same. I read the documentation but found nothing about it, nor in questions here at Stack.

The two are 'acceptable' and only writing style, or should I get used to using the second, in the sense that this may cause problems in the future?

Thank you!

P.S.: the specifications of this table, were those:

Answer 1

The theory is that a field (or combination of fields of the same table) is a primary key so NOT NULL and UNIQUE are implicit, and so I think NOT NULL would not even need to be explained in the declaration.

Even by what you say here (worth visiting for more information) declare the field as SERIAL also implies in NOT NULL.

So I think it’s just a matter of style to choose which way you prefer to declare PRIMARY KEY, and I also don’t see why to explain this NOT NULL in the field declaration.

The second case would make more sense if the primary key was composed of more than one field. I find your statement more readable than your colleagues.

And the name of the studio in my view should be declared NOT NULL, but it will depend on the business rule.

In practice it is certainly very common and appropriate to combine SERIAL and PRIMARY KEY, as both complement each other when generating an artificial identity based on a numerical sequence automatically generated and already indexed for the records of the table, usual need in relational databases.