u/AdorableMaids

When queries move between engines, these three always seem to show up. The SQL looks fine, but the behavior suddenly isn’t.

Dates are usually the first thing that breaks. GETDATE() in SQL Server, NOW() in Postgres, SYSDATE in Oracle. That part is obvious enough. The more annoying part is date arithmetic.

DATEADD(day, 1, mydate) works in SQL Server. Postgres wants interval syntax. Same logic, different syntax, and suddenly a query that looked harmless needs rewriting.

Nulls are another one. Most behavior is similar, but the small differences still bite. Null ordering is a good example. Postgres puts nulls last by default in ascending order. SQL Server puts them first. Same query, same data, different row order.

Strings might be the sneakiest one. SQL Server is often case-insensitive because of collation settings. Postgres is case-sensitive by default. A filter that worked fine in SQL Server can quietly miss rows after a migration because the casing doesn’t match.

None of this is really “edge case” stuff either. It’s normal engine behavior, which is probably why it slips through reviews so easily.

Which one has wasted the most time for your team?

Importing CSV data into PostgreSQL sounds simple until the file comes from a real system.

If it’s clean, COPY or \copy is usually fine. Matching columns, normal encoding, proper headers, no surprises.

The pain starts when the CSV is slightly cursed. Wrong delimiter, empty strings that should be NULL, dates in different formats, random extra columns, quotes inside quotes, or an Excel export that looks normal until Postgres disagrees.

For small imports, I still start with \copy: \copy table_name FROM 'file.csv' WITH CSV HEADER

But I don’t like loading messy files straight into the final table. I usually import into a staging table first and treat that data as suspicious. Then I can check what actually came in: row counts, weird NULLs, duplicates, broken dates, IDs that don’t match anything.

After that, moving clean rows into the real table feels much safer. A GUI tool can help when the file needs column mapping, preview, or quick fixes before import. I’ve tried this with DBeaver and dbForge Studio for PostgreSQL, but I still want validation SQL after the import, because the tool can load the file, but it won’t know what “correct” means for the app.

What do you use for importing CSV data into PostgreSQL? Plain COPY, pgAdmin, DBeaver, scripts, ETL tools, or something else?