Structurize tests and add coverage for base PostgreSQL features

[MBHuman]

Note: Before starting this issue #7 must be closed

!!! If some tests is working on postgresql, but not working on petacore, then tests can be added but with t.Skip() tag

Problem

Current test suite is not well structured and does not fully cover core PostgreSQL behavior. This makes it harder to:

• understand what is already tested vs. missing,
• extend tests without duplicating setup/boilerplate,
• confidently validate compatibility with PostgreSQL basics.

Proposal

Restructure the test suite

• Organize tests by feature area (e.g., DDL, DML, types, transactions, indexes).
• Introduce shared helpers/fixtures to reduce duplication (DB setup, cleanup, common assertions).
• Use consistent naming and conventions for test files and cases.

Add test cases covering base PostgreSQL features

• Add/extend tests to cover at least the following areas:
• DDL: CREATE/DROP TABLE, ALTER TABLE (add/drop column), constraints.
• DML: INSERT/UPDATE/DELETE, RETURNING, bulk inserts.
• Queries: SELECT, WHERE, ORDER BY, LIMIT/OFFSET, JOIN (inner/left), aggregations (GROUP BY, HAVING).
• Transactions: BEGIN/COMMIT/ROLLBACK, savepoints, isolation basics (where applicable).
• Types: integers, numeric/decimal, text/varchar, bool, timestamp/date, uuid, json/jsonb (if supported), bytea.
• Nullability & defaults: NULL, NOT NULL, default values, COALESCE.
• Indexes & constraints: primary key, unique, basic index usage, foreign keys (if supported).
• Errors & edge cases: constraint violations, type mismatch, syntax errors, boundary values.

Scope

• Test code changes only (structure + new tests).
• No changes to production behavior unless needed to fix an actual bug uncovered by tests.
• Keep CI runtime reasonable (prefer table-driven tests and reuse setup).

Acceptance Criteria

• Tests are grouped by feature area with shared utilities and minimal duplication.
• Coverage includes the “base” PostgreSQL feature set listed above (or a documented subset if some features are intentionally unsupported).
• CI passes reliably and test output is easy to interpret.

Notes / Open Questions

• Confirm which PostgreSQL features are considered “base” for this project (especially around JSONB, FKs, isolation level details).
• Decide whether tests should run against a real Postgres instance (docker) as a reference baseline or only against the project implementation.