Issue 147 postgres integration

[AcquaDiGiorgio]

Full integration with PostgreSQL

Used asyncpg as the driver because it is the fastest and one of the most used by the community

Had to change a few aspects that were MySQL specific. Those being unnamed Enums, which are not permitted in Postgres, and the way of returning the last inserted ID, which used result.lastrowid and postgres needs result.inserted_primary_key[0]

[fstagni]

Why? We are anyway always using UTC.

[AcquaDiGiorgio]

Is because we are specifying the timezone in datetime.now(tz=timezone.utc).
While this does not throw any errors in MySQL when the table does not accept a timezone, in PostgreSQL stops the execution due to conflicting formatting.

One way of fixing it is just to completely remove the timezone on the datetime.now function, which is not recommended and even RUFF marks it as a warning.
The other way is by telling the column to take into account the timezone, which in my opinion is the better way of implementing it.

MySQL:

• Changing the table property: 2024-09-26 14:00:32
• Removing tz=timezone.utc: 2024-09-26 14:05:53

No change, both result in the same date format.

PostgreSQL:

• Changing the table property: 2024-09-26 13:50:26.213893+00
• Removing tz=timezone.utc: 2024-09-26 13:55:57.840623

Timezone is or is not added at the end.

[chaen]

thanks a lot for the excellent work.
The big problem with this PR (and with running Postgres) is indeed the timezone awareness of the datetime.

We unfortunately cannot have timezone aware datetime in our DB as long as we use legacy DIRAC, as this would require too much change. This effectively mean that we cannot have Postgress for DBs which come from Legacy DIRAC as long as they are there.

2 options:

• have two "running modes" for the code, by which we have either the timezone awareness or not, depending on whether we still need to support DIRAC. This could maybe be hidden to some extent in the column type. We would need to asses how much work that is.
• just accept that we won't support timezone aware timestamp (and hence Postgres) as long as there is legacy DIRAC around.

In any case, there's the priority is quite clear: first port all the services to diracx before trying to change any db schemas (which hopefully will just be an alambic job by then).
The question is whether we want to try to implement these 2 running mode in the meantime.
I am not sure whether its worth it, but it needs investigations.

@AcquaDiGiorgio just to make things clear : these problems have nothing to do with the PR you have done ! You've just helped us discovering these problems ! :-)