Re: [GENERAL] Imperative Query Languages

Поиск
Список
Период
Сортировка
От Jason Dusek
Тема Re: [GENERAL] Imperative Query Languages
Дата
Msg-id CAO3NbwPw8cKeK__Nwwk8jLGWNZbezwsf8+4oiUx-6VOEjdBY_A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] Imperative Query Languages  (Chris Travers <chris.travers@gmail.com>)
Список pgsql-general

On Tue, 4 Jul 2017 at 23:57 Chris Travers chris.travers@gmail.com wrote:

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

The imperative integration is thin, I admit — it just the integration with for loops.

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.

What are some alternative interpretations of this query? Are you referring to which rows are candidates for locking? Or the order of locking?

Kind Regards,

Jason

В списке pgsql-general по дате отправления:

Предыдущее
От: Chris Travers
Дата:
Сообщение: Re: [GENERAL] Imperative Query Languages
Следующее
От: Moreno Andreo
Дата:
Сообщение: Re: [GENERAL] Invalid field size