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

On Wed, Feb 9, 2022 at 11:15 PM Guyren Howe <guyren(at)gmail(dot)com> wrote:

> 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.*
>
> I could see this as being extremely useful, I would support non standard
ways of subtracting from '*',not necessarily in that syntax.

>
> - *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
> <http://a.name>, b.email then an editor can give me autocomplete when I’m
> writing the select clause.*
>
> I see the benefit, but it's not big enough to support standard deviation
IMO. SQL grammar is already very complex and this wouldn't help, even if
it's deterministically parsable.

>
> - *Hierarchical schemas*
>
> This would violate the standard, and would be unclear. Rules are set,
identifier is [database.].[schema.][table.].column. and your change would
introduce ambiguity.

> *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*
>
> Not following this, can you elaborate specific uses?

>
> - *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.*
>
> Ditto above. Mostly we can work around this with dynamic SQL today without
too much effort.

>
> - *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*
>
> Postgres used to suport QUEL way back in the day. Being blunt, there is
zero chance of this happening in core. A query language translator out of
core, preprocessing the language into SQL, might work. SQL has evolved
far beyond what those languages could practically offer. Main benefit
here would be to better support relational division, which bizarrely has
yet to arrive in SQL.
*A portable, low-level API*

>
> - *An alternative to SQLite that provides CRUD operations on a
> Postgres database.*
>
> This has been frequently discussed in the archives. Short version, won't
happen; it would put too many constraints on the architecture.

merlin

>