TaPaKmsLexпри drop + create теряются все права на объект
это у тех кто не способен в роли и гранты прописывать на этапе разработке, а у тех кто мышкой дба наклацывают гранты возникают такие танцыДа, права не проблема.
Главная проблема в том, что при при drop + create в течении некоторого времени объекта не существует, и попытки его использования приведут к ошибкам. Что исключает применение некоторых удобных сценариев процесса разработки

ИМХО нужно всегда делать ALTER, т.е. писать скрипты так, как в первом посте ТС.

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

Если же вдруг (!) нужно поменять тип ф-ции со скалярного в табличный, то действуем так же, как при необходимости заменить процедуру на таблицу (ну, или на линкед-сервер, или на каталог полнотекстового поиска), то есть удаляем один объект, и создаём другой

TaPaKalexeyvg,
авторГлавная проблема в том, что при при drop + create в течении некоторого времени объекта не существует, и попытки его использования приведут к ошибкам. Что исключает применение некоторых удобных сценариев процесса разработки

интересно, мы меняем объект или группу связаных расчётами объектов и при этом мы никак не можем сказать на чём же отработали в момент нашего алтераДа, в целом так и есть.

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

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