I'd like Postgres more (and really want to) if they would at least implement more basic stuff like SQL:2011 and/or there was a good hosted deploy story - RDS/Aurora is fairly complex.
https://learn.microsoft.com/en-us/sql/tools/sqlpackage/sqlpa...
The APIs were historically part of Visual Studio, and only split out into dacfx recently.
Someone braver than me could consider automated deployment from github actions etc.
The hard part is that a lot of database schema changes cause data truncation (e.g. reducing the size of a column or re-ordering columns).
You still need someone to review the generated code if it throws an error for potential data loss.
Yeah, exactly what I meant by the terraform-like plan/apply stages. You generate the change script and save it as your "plan", and then have an apply step that takes a backup and runs the script.
Also, which features in particular are you missing in PostgreSQL? Merge was added with PostgreSQL 15 a year ago: https://modern-sql.com/caniuse/merge
100% agreed. It's remarkable how Datomic also arrived on the scene in the same era (2012) but actually managed to solve a lot of these hard issues of immutable versioning + schema evolution via a clean EAV-based information model and an emphasis on accrete-only schema changes.
I'm a big fan of your work by the way :)
I find the temporal table stuff really useful and they drastically simplify a number of requirements, so it's annoying that the only non-proprietary DB that supports it is maria.
https://en.wikipedia.org/wiki/SQL/PSM
This is so pervasive in both free and commercial databases, that it is a gaping hole in SQL Server where obvious functionality should be.
I have thousands of lines of this stuff that will never see the light of day in a conversion because of Sybase Transact-SQL.
Why is Microsoft addicted to this very much not standard language, that they did not even originate?
While not the shit-show of bugs it was upon introduction in SQL Server 2008, there are still reasons to be careful with MERGE in SQL Server: it can still deadlock with itself in some circumstances, has issues with filtered indexes, can cause problems with CDC (wrong operation(s) get logged), …
(I actually like SQL Server, but the implementation of MERGE found there-in is certainly not one of the things I like about it!)
Can’t comment on Sybase. Didn’t need any other platforms.
?
INSERT INTO [FROM] ([SELECT], [WHERE], [EQUALS]) VALUES( 'WHY YES', 'IT DOES', 'WORK')
WITH [WITH] AS (
SELECT [AS], [IN], [ON]
FROM [UNION]
WHERE [AND] = [OR]
),
[OUTER] AS (
SELECT [LEFT], [RIGHT], [FULL]
FROM [CROSS]
WHERE [INNER] = [OUTER]
),
[GROUP] AS (
SELECT COUNT(*) AS [HAVING]
FROM [ORDER]
GROUP BY [GROUP]
HAVING COUNT(*) > 1
)
SELECT
[WITH].[AS],
[OUTER].[LEFT],
[GROUP].[HAVING]
FROM
[WITH]
JOIN
[OUTER]
ON
[WITH].[IN] = [OUTER].[RIGHT]
LEFT JOIN
[GROUP]
ON
[WITH].[ON] = [GROUP].[HAVING]
WHERE
[WITH].[AS] = [OUTER].[LEFT]
AND
([GROUP].[HAVING] IS NULL OR [GROUP].[HAVING] > 1)
ORDER BY
[WITH].[AS] ASC;
Of surrounding by square brackets in SQL Server, like [so] instead of like "so", which despite being non-standard is more commonly used in the MS SQL world because its behaviour is much more consistent than quotes in that environment.
Quoted (rather than bracketed) identifiers are supported but it depends upon a setting which may vary per DB or procedure. It is common to see the option ON these days a some features¹ depend upon it, and many tools like MS's SSMS default it to ON, but this can not at all be relied upon. See https://learn.microsoft.com/en-us/sql/t-sql/statements/set-q...
--
[1] From the documentation: “SET QUOTED_IDENTIFIER must be ON when you are creating or changing indexes on computed columns or indexed views. If SET QUOTED_IDENTIFIER is OFF, then CREATE, UPDATE, INSERT, and DELETE statements will fail on tables with indexes on computed columns, or tables with indexed views.”