Re: Can we go beyond the standard to make Postgres radically better?

On Wed, Feb 9, 2022 at 10:15 PM Guyren Howe <guyren(at)gmail(dot)com> 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
> <http://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.