On Wed, Feb 9, 2022 at 10:15 PM Guyren Howe <guyren@xxxxxxxxx> wrote:
There are huge developer benefits available to focusing more on making a great relational programming environment, well outside the SQL standard.
Sure
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
Natural join sucks and "using" already does this. Not seeing how this meaningfully impacts views. in their current form.
I have asked for this in the past though...but it is so contrary to the fundamental design of SQL, and provides such limited benefit, that its omission seems like a net positive (if you factor in both novelty and development)
- 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.
select * from ..., then go back and change * to whatever columns you end up wanting and your editor can, in theory, do what you want. Dance with the person you brought.
- Hierarchical schemas
- 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.
See past and current discussions regarding modules. Improvement here is IMO the most worthy of attention (among this list, not globally)
- Other languages
- Tutorial D, Datalog, Quell, let’s open this puppy up!
Go talk to them. Adding more of these to the core is undesirable.
- SQL is a terrible, no good, very bad language
I'd rather live with SQL as it is and develop static analyzers and other related tools to make using it less problematic; in ways that we cannot do in the server without breaking existing code.
- A portable, low-level API
- An alternative to SQLite that provides CRUD operations on a Postgres database.
Not really understanding what features you are including in this one. Doesn't feel like something that belongs in core though. I'd rather efforts be made to make extension writing and installing easier (including the related "module" feature you note above).
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.
No one is saying we shouldn't or cannot do just that. Though frankly there is enough WIP in our commitfest to keep the majority of volunteers sufficiently busy on stuff that has two important attributes this email lacks - someone championing the feature and a functioning patch.
David J.
