Re: Can we go beyond the standard to make Postgres radically better? - Mailing list pgsql-general

From Merlin Moncure
Subject Re: Can we go beyond the standard to make Postgres radically better?
Date
Msg-id CAHyXU0zxpGmyTp+9TR6zemB8P1_fCVMrz0Hq5Rf4NB_BKapvXQ@mail.gmail.com
Whole thread Raw
In response to Re: Can we go beyond the standard to make Postgres radically better?  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Can we go beyond the standard to make Postgres radically better?  (Guyren Howe <guyren@gmail.com>)
List pgsql-general
On Thu, Feb 10, 2022 at 10:54 AM Merlin Moncure <mmoncure@gmail.com> wrote:
On Wed, Feb 9, 2022 at 11:15 PM Guyren Howe <guyren@gmail.com> wrote:
 
    • 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
 
FYI, there was a semi-serious commercial attempt to do this back in 2001, Dataphor. It's been opensourced.  Wikipedia has a pretty good write up on it:

IMNSHO suggestions like these should travel this technical path; take the data language you want and translate it into SQL.  Some of these translations will end up being complicated (read: slow).  Iterating this kind of thing outside of core would allow for faster development.

merlin

pgsql-general by date:

Previous
From: Garfield Lewis
Date:
Subject: Re: [EXT] Re: Passing XML column in an array
Next
From: Guyren Howe
Date:
Subject: Re: Can we go beyond the standard to make Postgres radically better?