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

From Chris Travers
Subject Re: [GENERAL] Imperative Query Languages
Date
Msg-id CAKt_Zfunz7RainjVrjzdV28zyJcPfuLkN4CTLpWqAfD8RstnNQ@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Imperative Query Languages  (Jason Dusek <jason.dusek@gmail.com>)
Responses Re: [GENERAL] Imperative Query Languages  (Jason Dusek <jason.dusek@gmail.com>)
List pgsql-general


On Wed, Jul 5, 2017 at 8:42 AM, Jason Dusek <jason.dusek@gmail.com> wrote:


If we imagine network databases have one layer:

  Imperative Plan

And SQL databases have two:

  Declarative Query -> Imperative Plan

It seems reasonable to say, LINQ, &al. have three: 

  Imperative Syntax -> Declarative Query -> Imperative Plan

Fortress is rather the same, since it translates imperative to functional to assembly.

I am curious where you see LINQ as starting at an imperative syntax.

Here's a good case that illustrates the problem I think.  Suppose the following is understood imperatively:

FOR x IN RANGE student
SELECT WHERE x.age < 25
PROJECT ALL(x), lock_if_possible(x.id)

Now, lock_if_possible has side effects.  If we understand this to be imperative, then we have no possibility of turning this into a declarative query because we are interested in the side effects.  So you cannot say that this is equivalent to the SQL of

SELECT *, lock_if_possible(id)
FROM student
WHERE age < 25

The reason is that while the imperative version represents *one* valid interpretation of the declarative, there are other interpretations of the declarative that are not at all equivalent.  The hoops we have to jump through to make this work in an imperative way in SQL are sometimes rather amusing.
 

Kind Regards,
  Jason



--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.

pgsql-general by date:

Previous
From: rjhb@bb-c.de (Rainer J.H. Brandt)
Date:
Subject: Re: [GENERAL] 64bit initdb failure on macOS 10.11 and 10.12
Next
From: Jason Dusek
Date:
Subject: Re: [GENERAL] Imperative Query Languages