I'm going to have to disagree with Aaron (and the accepted answer).
Aaron's approach is the way I like to deal with "DBA stuff" e.g. maintenance scripts. I would never want to do this with a library function that would be called by a user database.
Why? You'll be heading for the database equivalent of DLL Hell.
...Before Windows 2000, Windows was vulnerable to this because the COM
class table was shared across all users and processes. Only one COM
object, in one DLL/EXE could be declared as having a specific global
COM Class ID on a system. If any program needed to create an instance
of that class, it got whatever was the current centrally registered
implementation. As a result, an installation of a program that
installs a new version of a common object may inadvertently break
other programs that were previously installed.
Install .net 4.5 on a server running a .net 2.0 application and what happens? Nothing, you're application continues to use the 2.0 framework. Update your LastIndexOf function on a server hosting 3 applications databases (as part of an upgrade to one of them) and what happens? All three are now using the latest version.
The alternative is the approach adopted by SQL#. This is installed to a schema in each user database, so you can safely upgrade the database for Application-X without risking the stability of Application-Y.
If you're working in a tightly controlled change management environment you'll have no choice, you can't upgrade a shared component without testing all consumers of the component. If you're working somewhere a little more "fast and loose", you're free to take your chances with breaking something unintentionally with a patch/upgrade.