Postgres has since the outset gone beyond the SQL standard in many ways : types, inheritance, programmability, generality are all well beyond what SQL used to mandate and still well beyond the current standard.
There are huge developer benefits available to focusing more on making a great relational programming environment, well outside the SQL standard.
Examples of small things Postgres could have:
- SELECT * - b.a_id from a natural join b
- let me describe a select list by removing fields from a relation. In the example, I get all fields in the join of a and b other than the shared key, which I only get once.
- note how this simplifies maintaining views wrt changes in tables
- Let me put the FROM clause first
- if I can write FROM a join b SELECT a.height, a.name, b.email then an editor can give me autocomplete when I’m writing the select clause.
- Hierarchical schemas
Examples of larger things Postgres might have:
- First-class functions.
- A global-only namespace is dumb. Schemas are only slightly less dumb. The obvious way to store and call functions is as values of fields. Let me organize them how I choose
- Also let me pass around functions as values, let me make new ones and so on. Postgres is the best relational programming environment already because it has a decent type system and more general features. Let’s expand and also simplify that.
- Also nested function definitions, so top-level functions can be built out of local auxiliary functions.
- Other languages
- Tutorial D, Datalog, Quell, let’s open this puppy up!
- SQL is a terrible, no good, very bad language
- A portable, low-level API
- An alternative to SQLite that provides CRUD operations on a Postgres database.
I adore Postgres, but this is despite rather than because of SQL. By all means, let’s have a close-to-standard subset of features, but let’s fearlessly go beyond them when it would be obviously much better.
![]() |
