Все перечитал - ничего не нашел.
Слабая надежда осталась на форум - может все-таки возможно как-то.

Надо обновить параметры функций UDF без DROP/DECLARE (это очень сложно - перелапачивать все зависимости, их десятки-сотни). А именно - мне нужно только установить флаг FREE_IT у результата у нескольких ф-ций одной удфки.

Для < 3.0 работал скрипт (это обновление):



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

Может, как-то можно все-таки?

dimitrвроде никак, увы. В трекер я это уже заносил, но будет ли сделано к 3.0.1 - не обещаю.
Спасибо и на том, за надежду ;)

Ivan_Pisarevsky,

Нет, не предлагать, спасибо. Это все понятно. Для переходного теста на нескольких базах я так и сделаю, ручками.

Но только таких баз - несколько сотен, за 500 это точно. Размер обычно 1-4 ГБ, но единичные - и 30, и 300, и 700 ГБ. Хотя размер тут особой роли не играет. И при переходе на тройку все равно бэкап-рестор делать надо будет. Хотелось бы, чтоб апдейты отработали в штатном порядке, автоматически, после ручного бэкап-рестора. И вот понадобился такой апдейт блин.

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

hvladYuRockИ при переходе на тройку все равно бэкап-рестор делать надо будет. Хотелось бы, чтоб апдейты отработали в штатном порядке, автоматически, после ручного бэкап-рестора.Почему не до ? Т.е. на 2.5
Да, так подходит конечно.
Только сложно объяснить, почему надо делать именно так (тем, кто будет это делать). И путаница неизбежна.
Но дело даже не в этом - проблема решаема, да, таким способом.

Но мне кажется, не совсем логично и красиво, когда есть (и очень давно) CREATE OR ALTER PROCEDURE, ALTER PROCEDURE,
теперь есть то же для FUNCTION
а для EXTERNAL FUNCTION - нет.

В общем случае это не решит проблемы. Пусть сейчас я сделаю UPDATE RDB$* на старой версии и обновлючь на тройку. Где гарантия, что через год мне не понядобится такая же операция?

Ivan_PisarevskyYuRockНо мне кажется, не совсем логично и красивок проблеме подошли с другой стороны в 2.1:
кучу УДФ впилили внутрь и оные УДФ стали тупо не нужны.
И к чему эта фраза?
Я должен перелопатить десятки мегабайт кода (в том числе чужого, мне не доступного ) на уборку удф?
И затем потратить месяц на тестирование всего? (в том числе того, что мне не доступно)
Будем говорить прямо - сколько я заработаю на этом? Если нисколько - то не вижу смысла.

И как быть со специфическими удф-функциями, типа получить серию талона из номера клиента и полного номера?
Или получить плотность дизтоплива при температуре 15 градусов по текущей тепмературе и текущей плотности?
Эти функции тоже впилили в сервер?

Предлагаю закончить флейм.

Dimitry SibiryakovНе менять им параметры на лету не предлагать?
Я им не меняю параметры на лету. Если правильно понял.
В данный момент я просто изменил некоторые функции, которые работали неверно. Исправил ошибку. Для этого придется поменять параметр.

Ivan_PisarevskyТы согласен платить?
Нет, не согласен
И дальше что? Я спросил, мне ответили, что когда-нибудь это будет реализовано. Меня устраивает, спасибо. К чему дальнейшие разговоры - не понятно.

Еще я сказал, почему по моему мнению это удобно и красиво. Что я не так сделал?

Далее мне предлагали месяц бесплатно поработать, чтобы сделать так, чтобы просто все заработало как раньше, отлаженное и вылизанное. Я и отвечаю - спасибо, мне это не надо.

Симонов ДенисИли ты переходишь на 3.0 только ради SMP в супере?
Ну в основном да.
Симонов Денисчто-то мне кажется что это можно сделать и внутри PSQL функций, при небольшом оверхеде или даже вовсе без оного
Там огромные константные таблицы, формулы и т.д.
Конечно, теоретически все это можно переписать на PSQL, сделав огромнейшие функции и добавив в базу десяток таблиц. Да только, опять же, зачем? Времени это займет немало, а работать лучше не станет. По быстродействию точно будет хуже. Не проверял, конечно, но уверен.

miwaonline,

Это советские таблицы ;)
В Украине раньше эти же методы использовались. А сейчас придумали посовременнее :) - поточнее. Разброс больше в несколько сотен раз.

Но дела это не меняет. Смысла переводить рабочие части программы я не вижу.
К тому же, тот же код, что и в UDF, используется и в клиентских программах.