Paul Mossman wrote:
> Hi all,
>
> Looks like the solution to XX-7131 will have a DB patch that uses the
> SQL Procedural Language (PL/pgSQL).
>
> The language must be "created" in the DB before it can be used, so the
> patch ant target (in database.xml) is going to have a dependency on this
> new target:
>
> + <!--
> + Patches that use the SQL Procedural Language (PL/pgSQL) should
> depend on this task to ensure
> + the language is created. Because 'failonerror' is 'false', it can
> be run without problem even
> + when the language is already created.
> + -->
> + <target name="createlang-plpgsql">
> + <exec executable="createlang" failonerror="false">
> + <arg line="-U ${sipxconfig.db.user} plpgsql
> ${sipxconfig.db.name}" />
> + </exec>
> + </target>
>
> I'll of course test this with an SCS upgrade, which will tell me if
> PL/pgSQL is actually available by default in the commercial product.
>
> If all goes smooth, this should give us more flexibility in the DB
> patches we create going forward. (There'll be more that we can do with
> SQL, without resorting to manipulating the DB from Java during
> upgrades.)
>
This is a really nice improvement: in some case we now need to retrieve
information, run java code, and then drop the old table. If all can be done
from SQL patch it would simplify such cases significantly.
We probably should start dropping really old patches and really old init
task soon. As of now you can upgrade sipXconfig DB starting old the way
back with version 3.0. I think it would be OK to carry over 2-3 release
worth of patches. That would clean up database directory and shorten
database.xml significantly.
D.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
