Разницы во множественном числе, т.к там много категорий. Сколько - я пока не знаю.

Не считая очевидных, я достоверно знаю про две области где SQL и PL/SQL кажутся похожими, но таковыми не являются.

Все что ниже - про 11.2, на другие версии пока не смотрел.
В моем понимании могут быт пробелы или ошибки, конструктивные комментарии приветствуются.

Первая разница - это типы данных
У SQL фиксированный встроенный набор типов, это типы которые можно записать в колонку/поле.
Эти типы данных никак не связаны с декларациями в SYS.STANDARD, и на них нельзя повлиять средствами языка.
Это наверное задумано с точки зрения производительности, а также миграции/репликации.
У PL/SQL есть небольшое число встроенных типов (DATE_BASE, NUMBER_BASE,..) из которых создаются все стандартные, плюс есть возможность создавать уникальные типы данных как RECORD или OBJECT. Таким образом существуют стандартные типы PL/SQL, для которых нет аналогов в SQL. Самый известный из них - тип BOOLEAN, т.к. многие ощутили его отсутствие.
Это, кстати, неплохая причина избегать написания функций которые принимают или возвращают этот тип, если они могут быть полезны из селекта или другой конструкции SQL.

Приятное для меня открытие - что одноименные типы данных совпадают между таблицами и PL/SQL.

Это прямо гора с плеч. BINARY_DOUBLE - восемь байтов и там и там, и даже отвечает международному стандарту.
INTEGER - всего лишь constrained подтип от NUMBER, и там, и там.

А если бы я поверил тексту STANDARD пакета (там BINARY_DOUBLE=NUMBER), пришлось бы переживать что типы одноименные, но несовместимые.

Как сказал бы великий Козьма Прутков, "Если в STANDARD пакете увидишь декларации типов, не верь глазам своим!"

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

Спасибо, уже нашел по вашей подсказке про колонки с объектными типами, в руководстве версии 12, может это было и ранее.



А вот это очень интересно. Я сравнил главы про типы обоих руководств, и пришел к противоположному выводу.
Потом меня на некоторое время отвлек STANDARD пакет, который убедительно но неверно показывает BINARY_FLOAT=NUMBER, поэтому пришлось сделать несколько экспериментов чтобы убедиться как на самом деле.
Насколько я могу судить, одноименные типы совпадают полностью, если не считать разницу длины для VARCHAR2 в 11.2, что Оракл исправил позже.

Есть типы которые ведут себя по разному в SQL и PL/SQL? Это было бы неудобно.

Я разделяю это мнение. Эта тема - чтобы найти линию разграничения, где она размыта или неочевидна
К примеру:




Одинаковый смысл, одинаковый результат, одинаковое название функции, разница в скорости на порядок.

ОК, я понимаю что в первом случае функции нет, есть утверждение в форме функции которое развязывает руки оптимизатору.
Во втором - тезка первой, но уже функция, почти настоящая (она на самом деле вызывает встроенную, но оптимизатор уже скис)

Этот пример ведет себя схоже когда встречается в теле PL/SQL кода, а не в запросе, такая же разница.

Часть, с которой я затрудняюсь - это знать, какая из одноименных функций вызывается.
Может ли случиться, что я ненароком вызову функцию из пакета STANDARD, и все затормозится?

> Может ли случиться, что я ненароком вызову функцию из пакета STANDARD, и все затормозится?

Похоже, что не может. Мои попытки вызвать функции из sys.Standard без указания пакета не увенчались успехом.
Или использовалась одноименная встроенная функция SQL, или приходилось указывать sys.standard.to_mlslabel().
Это относится как к запросам, так и к селектам внутри PL/SQL кода.

Это упрощает картину.

Остается разобраться с несколькими назойливыми встроенными функциями, которые называются одинаково в SQL и в PL/SQL, но дают совершенно разные результаты.

Очень вовремя. Я как раз готовлю список литературы на октябрь. Вот только недавно спрашивал - какие есть хорошие книги кроме Грубера?

А про "мнение" не обижайтесь. Когда мои мнения выйдут на уровень фактов,я перестану быть новичком.

env,

Вы пытаетесь что-то добавить к теме, но ваши примеры вас уводят в сторону, и непонятно что вы хотите сказать.

Из последних двух примеров я понял что вы знакомы с библиотекой utl_raw.

Я тоже. Она появилась позднее чем две версии rawtohex().

Эти две версии rawtohex (одна в sql, другая в pl/sql) дают отличающиеся результаты для одинаковых параметров, что нетипично для Оракла и может привести к ошибке.

Лично к вам два вопроса:
- вы знали об этой разнице в поведении rawtohex()?
- вы считаете такая разница помогает или мешает программистам?

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

НеофитSQL,

Английский знаете?


Да, английский предпочитаю в документации.

Stax,

Спасибо. Документация Оракла мне поначалу показалась скудной на подробности и примеры, но я к ней привыкаю.

В частности, не хватает информации о версиях Оракла на странице конкретной функции (когда появилась, когда устарела), а также напрягает небрежное отношение к полноте информации. Например: "функции SQL всегда вернут null если в их параметрах есть null. Исключения: CONCAT, DECODE, DUMP, NVL, and REPLACE". В идеальной документации этот список исключений был бы полный, а тут пропущены NVL2() и возможно другие, о которых я не знаю.

Еще нашел несколько хороших сайтов, но это может быть против правил форума их упоминать.

Также по теме: я погуглил возможных других функций которые себя ведут по-разному в зависимости от контекста,
сузив поиск до сайта оракла и используя казенные выражения увиденные в описании SQL/RAWTOHEX.

Нашел много упоминаний несовместимости языка до- и после 8.1 (вряд ли сегодня актуально), отличия ТаймсТен особой версии 11.2, но никаких других конкретных функций не увидел, похоже что RAWTOHEX это единственное исключение, и разница в поведении задокументирована в руководстве языка SQL (но не в руководстве PL/SQL).

Да, я так уже делал, когда подробно разбирался в своем примере. Параметр всегда 'z' даст ошибку для PL/SQL.
> [вы] ожидаете, что неявная конвертация типов одинаково отработает в SQL и PL/SQL машинах.
Я этот пример понимал несколько иначе: неявная конвертация типа произошла только для SQL; в PL/SQL части конвертации, по-моему, нет, поскольку RAW и VARCHAR2 идентичны в PL/SQL и не требуют конверсий.
Источник: STANDARD пакет, где "subtype RAW is VARCHAR2;"

> А это различие явно прописано в документации.
Я пока этого не нашел в документации.
У вас есть примеры, когда конверсия типов происходит с разными значениями результатов в SQL и PL/SQL?
Или если нет примера, ткните в документацию, я почему-то это пока не вижу. Заранее спасибо.


Этак однажды и про NLS ветку откроете. Пожалуйста - to_char/to_date/to_number, эти даже в одной SQL-машине могут в корявых ручонках вернуть разные результаты.[/quot]

Подкрепите пожалуйста примером аналогичным моему (компилируется/исполняется без ошибок, одинаковый синтакс, одинаковый вход, разный выход).
Я как раз с утра сделал поиск других одноименных функций которые ведут себя по разному в SQL и PL/SQL. Не нашел.
Вы знаете про такие?

Мне кажется, что вы неверно используете слово "неявная конвертация" в данном случае.
Это легко проверить без моей помощи, у нас более интересная тема. Если застрянете, я подскажу.

Я понимаю что это громкое утверждение, но "Платон мне друг, а истина дороже" :) Берите попкорн, докопаемся до правды.
(ответы в конце)

Если бы неявная конвертация вызывала проблему, то выражение с явной конвертацией исполнялось бы идентично.



Как мы видим, это не так. Значит, неявная конвертация тут ни при чем.
(Кстати, вы ошибочно полагали что в SQL '5' это тип VARCHAR2, это не так. Но тут это неважно).

Возьмем другую встроенную функцию которая может принять тип RAW, их не так уж много.



Что за дела, елки-палки? Снова отличается, но уже по-другому! :)

Может это тип RAW такой необычный? Давайте попробуем DATE:



Ошибка.. Встроенной конверсии DATE->RAW в SQL нет, значит и неявно она также выполниться не может.

Однако:



Тут дело не в конверсии..


Если дочитали до этого места, надеюсь что получили удовольствие.

Теперь ответы.

rawtohex() это очень старая встроенная функция SQL, и она определена для всех скалярных типов, кроме LONG, LONG RAW, CLOB, BLOB, и BFILE. Так говорит документация Оракла, и это подтверждают мои эксперименты. Поскольку она определена для всех типов, она видит параметр без всякой конвертации, и выбрасывает 16-ричный дамп памяти переданного объекта.
В этом она очень похожа на встроенные функции dump() и vsize(), которые тоже работают без конвертации, как Оракл велел.
Ее разрешается использовать с любыми типами (кроме короткого списка выше), это поддерживается.

литерал '5' на самом деле тип 96 (это CHAR/NCHAR), а VARCHAR2 это тип 1. Конверсии между ними выполняются незаметно, поэтому даже после многих год работы с Ораклом это можно не знать. Я это знаю потому что копаюсь "где не надо".

Одноименная PL/SQL функция sys.standard.rawtohex() определена только для параметра типа RAW (голые байты).
Тип RAW определен в STANDARD пакете в точности как VARCHAR2, но это неправда - мы уже видели много раз что определению типов в stdspec.sql доверять нельзя. В моем файле это строка 35: subtype RAW is VARCHAR2;

Когда-то где-то Оракл решил осуществить неявные касты между VARCHAR* и RAW, хотя эти преобразования не самые частые, и вычислительно не бесплатные, что сделало PL/SQL функции hextoraw() и rawtohex() избыточными.

Это почва для малопонятного кода и ошибок (или развлечений, для определенного склада ума):