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.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"