alexey_tmА все просто, чтобы именовать таблицу и /или колонку "русским именем" её нужно заключить в '', чтобы обратиться к ней, надо проделать тоже самое...
Не нужно ее заключать в кавычки. Это добавит к глюкам русских букв еще и глюки неправильного регистра символов.

alexey_tmВообще-то для того, чтобы определить кто куда ссылается, существует словать данных...
То есть Вы предпочитаете получить исключение вида "constraint SYS_012345 violated" и отправиться в словарь данных смотреть, что это за constraint?

Нет, спасибо. Лично мне "constraint FK_TABLE1_TABLE2" куда как удобнее. Время, знаете ли, стоит денег.

LongsvanoАга. Классная перегрузка. Только такое перегрузить не может почемуто:
Передергиваете. В приведенном Вами примере вообще нет перегрузки.

Почему не видится верхняя функция?
Видится. В своей области видимости. Хотя если не знать концепций... Попробуйте

LongsvanoЗапишем еще раз: перегрузка в PL/SQL - кастрированная.
Запишем еще раз: некто Longsvano не знает, что есть перегрузка, однако употребляет это слово и строит на этой основе какие-то теории.

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

LongsvanoМне будет достаточно вашего определия перегрузки и ресурса, откуда вы его возьмете. А потом посмотрим подходит ли мой пример под перегрузку или нет.
Боюсь, книги не очень подойдут как ресурс. Из того, что легко найти, в целом верное определение - http://www.cs.ucc.ie/~dgb/courses/swd/glossary.html#O В нем только нужно понять, что есть single scope (отождествление этого с "просто scope" будет неверным).

Коротко: уже очень давно существует понятие области видимости идентификатора (display, scope). Сейчас в подавляющем большинстве случаев, область видимости идентификатора (и идентифицированного им объекта, соответственно) - часть блока, в котором объявлен этот идентификатор, после места объявления. Это и есть single scope из определения выше. Далее: в ЯП (впервые, по-моему, в Алголе, хотя могу ошибаться) потребовалась концепция взаимодействия display-ев, подключения одних в другие. То, что сейчас существует в виде вложенных блоков, использования внешних модулей и пакетов, наследования (видимость идентификаторов из предка), namespace-ов итп. Как только появилась эта потребность, появились и правила, определяющие приоритет видимости совпадающих идентификаторов из разных областей видимости. Во всех известных мне реализациях действует принцип - идентификатор, объявленный локально (в текущем блоке), скрывает идентификатор, подключаемый из внешнего блока. Наконец, что же есть перегрузка (overloading). Это фича объявления в одном display-е нескольких одноименных объектов, различимых по контексту использования.

ModelRОракл не лезет в вышестоящий скоуп если нашел имя в текущем,
Причем это правильный (необходимый) подход. Иначе возможен следующий вариант: из-за изменения кода в одном месте стал иначе работать код в другом месте. Скажем:

LongsvanoТут вам уже ответили.
Да неужто? Между моим сообщением (когда явно "еще не ответили") и Вашим (когда вроде как "уже ответили") ровно одно письмо, при этом это ответ Apex-у от locky. Полагаете, я - виртуал Apex-а?

LongsvanoВообще как это разрешение имен реализуется по-уму на низком уровне:
Хм. Ну-ну.

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

LongsvanoПо-моему это недоработка или кривизна или косяк. О чем собственно я и говорил.
Разумеется, Вы имеете право так считать. Сугубо технически любую концепцию можно назвать именно так.

Longsvano
Поправлюсь. "Не поняли" - пожалуй, неверно, скорее "не оценили".

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

Разумеется, предпочитаемая Вами концепция имеет право на жизнь. Но это совершенно не повод считать другую (и имхо - лучшую) кривой. Из вариантов "можно сделать А, защищен от Б" и "можно сделать А, нет защиты от Б" я почему-то предпочитаю первый.

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

LongsvanoОднако, зная как медленно развивается PL/SQL, что он до сих пор не может банально повторить концекции С 30-и летней давности или Perl-a 10-и летней давности, то остается только брюзжать.
PL/SQL в основном повторяет концепции ADA 25-летней давности. И совершенно не собирается повторять концепции одного опасного языка и одного плохого языка.