Re: Can we go beyond the standard to make Postgres radically better?
On Wed, Feb 9, 2022 at 11:15 PM Guyren Howe <guyren@gmail.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, 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
В списке pgsql-general по дате отправления: