Re: [GENERAL] Imperative Query Languages - Mailing list pgsql-general

From Merlin Moncure
Subject Re: [GENERAL] Imperative Query Languages
Date
Msg-id CAHyXU0zHYmH_vDDN5YVyFd6bUHw-hviAYW=tY58aABYeapF_ng@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Imperative Query Languages  (Christopher Browne <cbbrowne@gmail.com>)
Responses Re: [GENERAL] Imperative Query Languages  ("dandl" <david@andl.org>)
List pgsql-general
On Mon, Jul 10, 2017 at 4:26 PM, Christopher Browne <cbbrowne@gmail.com> wrote:
> On 5 July 2017 at 01:22, Jason Dusek <jason.dusek@gmail.com> wrote:
>> Hi All,
>>
>> This more of a general interest than specifically Postgres question. Are
>> there any “semi-imperative” query languages that have been tried in the
>> past? I’m imagining a language where something like this:
>>
>> for employee in employees:
>>     for department in department:
>>         if employee.department == department.department and
>>            department.name == "infosec":
>>             yield employee.employee, employee.name, employee.location,
>> employee.favorite_drink
>>
>> would be planned and executed like this:
>>
>> SELECT employee.employee, employee.name, employee.location,
>> employee.favorite_drink
>>   FROM employee JOIN department USING (department)
>>  WHERE department.name == "infosec"
>>
>> The only language I can think of that is vaguely like this is Fortress, in
>> that it attempts to emulate pseudocode and Fortran very closely while being
>> fundamentally a dataflow language.
>
> It's probably of broader interest to consider some sort of "more relational"
> language that would, in effect, be "more declarative" as opposed to
> "more imperative" than SQL.  (I'd not be keen on heading back to
> CODASYL!!!)
>
> The notable example of such would be the "Tutorial D" language
> attributable to Darwen and Date's "Third Manifesto"
>
> https://en.wikipedia.org/wiki/D_(data_language_specification)
> http://wiki.c2.com/?TutorialDee
>
> Unfortunately, the attempts to construct implementations of D
> have all pretty much remained at the "toy" point, experiments
> that few beyond the implementors seem to treat as realistic
> SQL successors.
>
> Another option, in principle, would be to consider QUEL, which
> was what Stonebraker used initially as the query languages for
> Ingres and Postgres.
>
> https://en.wikipedia.org/wiki/QUEL_query_languages
>
> None of these options seem to be dominantly better than SQL,
> and for something to supplant SQL, it would need to be a
> fair bit better.

I'd like to see a SQL variant (maybe preprocessed) with an algebraic
syntax.  My biggest gripes with SQL are all the keywords (there are
other spoken languages than English??) and the unnecessarily irregular
syntax.

merlin


pgsql-general by date:

Previous
From: Adam Brusselback
Date:
Subject: Re: [GENERAL] Materialised view - refresh
Next
From: "dandl"
Date:
Subject: Re: [GENERAL] Imperative Query Languages