tldr: этот пакет SYS.STANDARD - он "живой" или "справочный"?
Мое исследование говорит, что справочный и написан в псевдокоде. В нем есть ошибки и неверные посылы, поэтому в отличие от настоящих исходников он не может считаться истиной в последней инстанции. Все же, есть польза от его прочтения.

Я почитал SYS.STANDARD на досуге, там есть немало любопытных приемчиков и комментариев.
Заметил некоторые нестыковки, как с документацией так и с функционалом по факту, поэтому возник вопрос в [subj].

Нестыковка с документацией:
В пакете STANDARD написано следующее:



у меня в версии 11.2 PL/SQL тип PLS_/BINARY_INTEGER определен как ограниченный подтип NUMBER, что есть десятичное число переменной длины. Документация обещает что тип BINARY_INTEGER (также PLS_INTEGER) это 32-битные переменные, которые хранятся в естественном для компьютера двоичном формате и быстрее работают с арифметикой.
Поскольку dump() в PL/SQL не доступен, я не смог проверить напрямик как BINARY_INTEGER хранится в памяти.
Однако по косвенным признакам (скорость исполнения бит операций над PLS_INTEGER в разы быстрее), документация права.

Нестыковка с фактом:
В пакете определены две полиморфные функции, с разными типами параметров.



Из практики я знаю, что попытка вызова полиморфных функций с null параметром даст ошибку компиляции PLS-00307.
Однако, я могу вызывать bitand(null,null) без ошибок, т.е. эта функция определена не так, как записано в пакете STANDARD.

Вот еще более очевидный пример несоответствия факту:



- синтаксическая ошибка, одинарные кавычки.
- запрещенная операция, для подтипов NUMBER запрещен диапазон (PLS-00572: improper constraint form used)
- n binary_integer := -2147483648 ; -- присваивание вне диапазона значений работает, ошибки нет.

Моя догадка, что этот пакет компилируется совсем другим компилятором, который понимает определение операторов, прагму 'interface' и кавычки в запрещенных определениях подтипов. Судя по присутствию восклицаний и имен разработчиков в комментариях, этот файл не сильно чистили для публики. Просто его нельзя воспринимать как PL/SQL код и делать выводы как если бы он был таковым.

Не думал что кого-то заденет слово "практика". Я имел в виду из прикладного эксперимента, а не из теоретических рассуждений основанных на богатом жизненном опыте SQL. Ибо с позиции SQL-стажа я рассуждать пока не могу, а вот эксперимент - легко.

В этом конкретном примере, я заметил что декларации одной из функций в STANDARD не объясняют поведение моей системы.



Из практики (о ней чуть ниже) я знаю, что в этом случае вызов bitand(null,null) должен быть пойман на стадии компиляции, однако это не происходит.



Эксперимент: я создал пакет "nonstd" с двумя функциями с аналогичными сигнатурами. Имя поменял на MySum.




Выводы в начале темы. Если кто-то хочет проверить на своей платформе, код ниже.

Это утверждение не сочетается с наличием синтаксических ошибок в SYS.STANDARD.
К примеру,


не компилируется по двум причинам, указанным в первом сообщении.

Если бы компилировалось, то присваивание


выдавало бы ошибку.

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

Вы можете привести какое-либо проверяемое обоснование вашего утверждения?

Признаю ошибку.
Мой эксперимент был проведен неверно, т.к. я не знал о разнице между SQL bitand() и PL/SQL bitand(). Теперь знаю.
Этот конкретный довод считать недействительным.

Когда читаешь дискуссию с середины, она кажется вырванной из контекста.
Посмотрите в первом сообщении темы, там в первой дюжине строк все указано, в том числе

subtype INTEGER is NUMBER(38,0);

Это также и мое заключение. Например, тип NUMBER_BASE или декларация операторов - попытки их использовать в своем модуле дают сообщение что это только для "STANDARD" и ни для кого другого. Тут вряд ли есть два мнения - сам Оракл в ошибке говорит об особом статусе пакета STANDARD, упоминая его по имени:

PLS-00504: type NUMBER_BASE may not be used outside of package STANDARD

Далее, исходя из конфликта между текстом SYS.STANDARD (где, к примеру, PLS_INTEGER показан как субтип NUMBER) и реальностью (где PLS_INTEGER использует двоичный формат), и некоторых других наблюдений, я думаю что STANDARD может быть полезен для обучения - как создатели делают некоторые вещи, но на него нельзя полагаться как на истину в последней инстанции, как это бывает с open source, или например API header files.

Другими словами - поскольку STANDARD/spec содержит некоторые лживые декларации, он не являются определяющим для поведения компилятора, и я подозреваю что компилятор моего сервера не смотрит туда вообще, а руководствуется встроенными правилами.

Насчет тела SYS.STANDARD/body я пока не уверен. Похоже, что оно тоже нерабочее, в отличие от других wrapped системных пакетов, и было включено только для образования. Там тоже есть что почитать.

Я до недавнего времени слышал, но не встречался, т.к. с плавающей точкой не работал.

Поскольку (согласно Ораклу и вопреки тексту STANDARD/spec) BINARY_INTEGER это двоичная 32-битная переменная, отрицательный ноль там быть не должен.

Проверим, ибо эксперимент важнее рассуждений:



Печатает -1073741824

Вывод - как все другие 32-битные двоичные числа со знаком, BINARY_INTEGER использует интервал (-2147483648,2147483647).
Декларация в STANDARD была сделана симметричной или для красоты, или в попытке предотвратить exception при смене знака.
Но это не сработало:

Я не пытаюсь обидеть твоего любимого ребенка, поэтому "а у вас негров линчуют" тут не очень подходит.

Когда я выпускал header files для MSDN, мы туда только правду размещали. Т.е. за Windows SDK/DDK я ручаюсь, по крайней мере до семерки. С чем запускался мейк для сборки Винды - то и шло всем программистам, без правок.

Люблю этот форум, узнаю много нового.

Booby, вы уверены что "binary_integer не всегда был машинным", или просто так сказали?

Например, в версии 7.х, он уже был машинным.
Источник: документация версии 7.3 https://docs.oracle.com/pdf/A32536_1.pdf?xd_co_f=30bdac43-db00-4c73-b23f-ab7dceabc8ab

Я не сразу смог прочитать предложение выше, поэтому отвечаю с задержкой.

Вы не правы.

В случае пакета SYS.STANDARD, о котором идет речь, типы и подтипы пакета обязаны совпадать с типами дефолтного пространства, т.е. не являются локальными для пакета и не требуют указания sys.standard. перед ними.
Это особенность этого пакета.

Источник: документация Оракл. https://docs.oracle.com/cd/A57673_01/DOC/server/doc/PLS23/ch8.htm

Вячеслав Любомудров,

Я не все смог понять в вашем примере, но вижу что вы пользуетесь версией 18 чтобы опровергнуть мои выводы о 11.2.

Когда у меня будет доступ к 18/19, я сделаю сравнительный анализ.

Я вижу, произошла подмена понятий (соломенный аргумент).

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

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

Мой тезис в самом начале этого сообщения: текст пакета SYS.STANDARD (1)справочный, и (2)написан в псевдокоде.
Мне это интересно как разработчику использующему PL/SQL как один из многих языков для выполнения моих задач.
Тема недостаточно широко раскрытая в интернете, но интересная мне, поэтому я захотел в нее углубиться.
Я использовал несколько доводов, один из которых оказался ошибочным и был опровергнут (довод с полиморфным bitand).

То, что этот текст написан на языке отличающемся от стандартного PL/SQL нет сомнений, вторую половину тезиса можно закрыть.

Теперь, несколько дней спустя и прочитав примеры от местных старейшин (включая сообщение 2012 года от Вячеслава ибн Владивосток) а также несколько профильных блогов, вижу что текст этого пакета, который содержится в stdspec.sql/stdbody.sql (в ранних версиях Оракла в catalog.sql/catproc.sql) не только присутствует, но и активно используется для начального формирования среды PL/SQL.

Кроме того, и это здесь важно - в stdspec.sql можно поменять значение константы, "накатить" его заново, и эта константа изменится в среде PL/SQL. Это говорит о том, что stdspec.sql - не просто свадебный генерал, а как минимум установочный скрипт с синтаксом напоминающим PL/SQL. Как максимум - полноценный PL/SQL с особыми расширениями зарезервированными для STANDARD.

Mы обычно понимаем разницу между компилятором и скриптом инсталляции. Если я запустил .msi или .deb или .sh файл на своем компьютере, это еще не значит что "я скомпилировал пакет" - только что я его установил. Даже если я поменял в установочном скрипте константу или две.

Чтобы определиться, является ли синтакс stdspec.sql расширением языка PL/SQL или установочным скриптом с похожим синтаксом но с ограниченными возможностями, нужно сначала определиться с критериями оценки, а потом эти критерии испытать. Научный метод, и все такое.

Возможные критерии:
- кто компилирует stdspec.sql (если штатный компилятор, голос в пользу расширения языка)
- языковые возможности доступные в stdspec.sql (если там скудное подмножество PL/SQL, голос в пользу инсталлятора)
- количество семантических конфликтов, когда одинаковый код имеет разное значение в stdspec/body, и других местах.
и т.д.

Также я хочу поблагодарить Вячеслава, который не ограничился "да все там компилится", а написал подробную иллюстрацию процесса специально для "neofit" :)

Было бы еще более честно написать что это кардинально другой тип, как это делается с другими типами,
ведь INTEGER это NUMBER, и для подтипов INTEGER/NUMBER нельзя использовать RANGE (ошибка PLS-00572)

Например:

type BINARY_INTEGER is BINARY32_BASE;

но почему-то в версии 11.2 Оракл так не сделал.

Не совсем так. В 11.2 определение выглядит так:

subtype BINARY_INTEGER is INTEGER range '-2147483647'..2147483647;

В свою очередь INTEGER - подтип NUMBER, и т.д.
Примешивать тип NUMBER_BASE к этой конкретной дискуссии нет необходимости.
Иначе любое обсуждение типов можно привести к "а там в самом начале _BASE", что ничего не дает.



Не совсем так. Я сказал что он написан в псевдокоде по конкретным причинам, которые были указаны ранее.

Во-первых, синтакс отличается в местах, где нет такой необходимости. Это намек на отдельный независимый парсер (а не просто расширения к языку). Во-вторых, одинаковые выражения означают разные вещи в PL/SQL и в языке модуля STANDARD.
Есть другие, менее понятные для меня расхождения, но пока эти два.

Если вы человек сведущий в этой теме и со сформировавшимся мнением, я предлагаю вам выдвинуть собственный тезис и критерий его правильности. Вам это позволит поучаствовать в дискуссии на равных, а не довольствоваться только поиском ошибок в доводах других (что тоже важная часть научного подхода поиска истины).

Посмотрите критерии "компилятор или инсталлятор" пару сообщений назад, там есть возможность дополнить и расширить.

Я прочитал ваш пример, но он не относится к теме. Я думаю вы сами это понимаете, как впрочем и все читатели.

По поводу "О, уже пошло деление на достойных участвовать в "дискуссии" и недостойных." это вы зря.

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

Я могу только предложить как вы можете более полно поучаствовать в этой теме,
я не могу вас заставить отвлекаться на "а я еще и вот так умею, хоть это не в тему" примеры.
Да и не хотел бы; может вам не комфортно свой тезис выдвигать по какой-нибудь личной причине.

У меня достаточно простые задачи в PL/SQL, которые не требуют обширных знаний и могут решаться новичком вроде меня.
Поскольку насущные задачи квалификацию особо не повысят, остаются книги а также ...

Мне действительно интересно нырнуть под капот и посмотреть как разработчики Оракла решали ту или иную проблему.
Ограничения, ошибки или срезание углов (как с BINARY_INTEGER, или rowid) вызывают особый интерес, т.к. это бывает признаком сложных проблем, или тупиков архитектуры. Про которые мне интересно подумать и расширить кругозор.
Например, я сейчас смотрю как оракл вызывает С библиотеки. Создатели считали это абсолютно необходимым для скорости, но похоже что в 11.2 только для себя, скорее всего из соображений безопасности. Также интересно как Оракл поступился безопасностью для ускорения исполнения кода в STANDARD, и что это означает для тех кто этот пакет модифицируют.

Надеюсь я ответил на ваш вопрос.

ап.

Мне тоже интересен авторитетный ответ на этот вопрос.

Судя по интернету, ответ нет, т.к. при отсутствии STANDARD компилятор отказывается работать - мол нету STANDARD, и скомпилировать STANDARD обычными средствами тоже не получается (снова - нету STANDARD).
Поэтому приходится запускать особые скрипты чтоб этот STANDARD заиметь, или как тут выразились, "накатать".

https://db-blog.web.cern.ch/blog/franck-pachot/2018-12-minimal-oracle
По ссылке описаны страдания человека, который развлекался установкой Оракла в абсолютно минимальной конфигурации, значительно меньше чем любая конфигурация рекомендуемая или поддерживаемая Ораклом.

graycode,

спасибо за совет. C/C++ и несколько ассемблеров я изучил в начале карьеры, собственно ими и занимался.
Там для меня все вроде как понятно, исключая прогресс в C++ стандарте за крайние годы.

> Зачем его [STANDARD] модифицировать? Oracle поставляет продукт решающий определенные задачи,
> если есть сильно большое желание помочь Oracle с этим, то нужно идти работать непосредственно в сам Oracle.

Мне не надо, но я знаю что человек с этого форума (Вячеслав) делал небольшое изменение прошлом, по бизнес необходимости.

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

Из этого я заключил что по крайней мере в версии 10 этот пакет не пустышка для отвода глаз, которую Оракл как бы "типа компилит" с предсказуемо одинаковым результатом и выставлением флажка VALID. Как минимум тянет на инсталл скрипт, т.к. читает какие-то константы из этого stdspec.sql. Чем читает, еще пока не разобрался. Похоже, что не штатным компилятором, пока не уверен.

Что-то последнее время я мало кода постил.

Вот загадка, сам придумал. Вроде в тему - см. комментарии.





У меня на оракле 11.2 дает неожиданный результат.

Неожиданно, если полагаться на STANDARD пакет, героя этой темы.
Если читать stdspec.sql, с которым вы хорошо знакомы, то там недалеко от начала файла можно заметить:




Синтакс совершенно однозначный. оба - подтипы NULL.
Попробуем сделать точно так же:




и... тишина.

Это означает что хотя в файле stdspec.sql присутствуют определения типов, Оракл забивает на некоторые из них, и пользуется встроенными. Это BINARY_INTEGER, PLS_INTEGER, BINARY_FLOAT и BINARY_DOUBLE.

То же самое касается нескольких функций. Я пока наугад пальцем потыкал, нашел пару.

Любопытно, конечно, почему эти бесполезные и неверные определения типов там присутствуют.
Также интересно, какие еще существуют подвохи. Ведь иногда приходится заглянуть в STANDARD, чтобы посмотреть, к примеру, все варианты полиморфной функции. А так не знаешь даже правда там, или нет.