Здравствуйте, vdimas, Вы писали:

V>Но с т.з. типа T+1 — это вполне себе валидное значение.
V>Дальше продолжать?

Оно валидное, просто несравнимое. По соседству Sinclair уже отписался о варианте с unknown.

V>Можно оределить и оператор < для области опеделения T+1, если хочется.

Можно определить оператор сравнения массива и числа, только это не будет иметь смысла.

S>>Они равны или не равны? Во всех этих случаях ответ false. Поэтому нельзя сравнить значение поля с null — это всегда false, даже не имеет смысла сравнивать.

V>Имеет, имеет.
V>К тому же, тривиально реализуемо.

Смотрите, вы сравниваете любое значение с unknown, результат всегда будет unknown — смысл в таком сравнении? Можно просто записать if (false) { do_something() } — эффект будет точно тот же.

V>Нет в SQL никакой реляционной алгебры. Есть бестиповое реляционное исчисление в исходнике.
V>Бестиповое — потому что сам язык имеет скриптовую природу, т.е. типизация тут сугубо динамическая.

Так типизация динамическая, или язык бестиповой? Все столбцы имеют строго определённый тип, на любом этапе представления имеют строго определённую последовательность столбцов — где тут отсутствие типов? Да и, если на то пошло, где тут динамическая типизация? Вы можете изменить структуру представления только заново его отобразив, получив по сути новый тип.

V>Ну да, почти все скриптовые языки всегда "отлично справляются".
V>Но большие простыни кода на них писать не рекомендуется.

Но пишут и всё работает.

V>Возвращались бы типизированные записи, т.е. байты, которые заранее известно как реинтерпретировать, т.е. без динамического маппинга из некоего Recordset с проверкой типа каждого значения каждого поля из каждой строки, верно?

Не, я имел в виду скорее сериализацию в xml или бинарное представление. Простая ситуация — есть запрос который запрашивает только часть полей таблицы — как тут прикрутить типизированные записи? Или возвращать запись целиком, даже если понадобилось только одно поле из неё? Неэффективно нифига, как бы.

Здравствуйте, vdimas, Вы писали:

V>Но с т.з. типа T+1 — это вполне себе валидное значение.
V>Дальше продолжать?

Оно валидное, просто несравнимое. По соседству Sinclair уже отписался о варианте с unknown.

V>Можно оределить и оператор < для области опеделения T+1, если хочется.

Можно определить оператор сравнения массива и числа, только это не будет иметь смысла.

S>>Они равны или не равны? Во всех этих случаях ответ false. Поэтому нельзя сравнить значение поля с null — это всегда false, даже не имеет смысла сравнивать.

V>Имеет, имеет.
V>К тому же, тривиально реализуемо.

Смотрите, вы сравниваете любое значение с unknown, результат всегда будет unknown — смысл в таком сравнении? Можно просто записать if (false) { do_something() } — эффект будет точно тот же.

V>Нет в SQL никакой реляционной алгебры. Есть бестиповое реляционное исчисление в исходнике.
V>Бестиповое — потому что сам язык имеет скриптовую природу, т.е. типизация тут сугубо динамическая.

Так типизация динамическая, или язык бестиповой? Все столбцы имеют строго определённый тип, на любом этапе представления имеют строго определённую последовательность столбцов — где тут отсутствие типов? Да и, если на то пошло, где тут динамическая типизация? Вы можете изменить структуру представления только заново его отобразив, получив по сути новый тип(*).

V>Ну да, почти все скриптовые языки всегда "отлично справляются".
V>Но большие простыни кода на них писать не рекомендуется.

Но пишут и всё работает.

V>Возвращались бы типизированные записи, т.е. байты, которые заранее известно как реинтерпретировать, т.е. без динамического маппинга из некоего Recordset с проверкой типа каждого значения каждого поля из каждой строки, верно?

Не, я имел в виду скорее сериализацию в xml или бинарное представление. Простая ситуация — есть запрос который запрашивает только часть полей таблицы — как тут прикрутить типизированные записи? Или возвращать запись целиком, даже если понадобилось только одно поле из неё? Неэффективно нифига, как бы.

(*) Понимаю что рискую нарваться на обсуждение строгой, не строгой и немного-строгой,-но-не-очень типизации. Не надо.