On Tue, Sep 21, 2010 at 5:12 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2010/9/21 Joshua D. Drake <jd@commandprompt.com>:
>> On Tue, 2010-09-21 at 14:56 -0500, Rhys A.D. Stewart wrote:
>>> hey all,
>>>
>>> I think versioned pl/[pgsql|python|perl|bash|java] functions would be
>>> a great addition to 9.1. Imagine that instead of CREATE OR REPLACE
>>> FUNCTION you could do CREATE AND VERSION FUNCTION and then all
>>> modifications to the function could be versioned so that you could
>>> revert/rollback to a specific version of the function a la
>>> git/svn...and then you could do diffs and what not so that you
>>> wouldn't have to rely on text files which get lost because they were
>>> on a tiny jump drive.....
>>>
>>
>> Hmmm, it seems this could be done relatively simply with the ability to
>> put triggers on system catalogs. The tablelog contrib function would
>> allow us to do this.
>
> After ten years with stored procedures I am thinking so this is not
> too well technique. Much better is writing stored procedures to a file
> and using usual tools for file's versioning. We did some tools for
> storing a versions inside database, but still we prefer a standard
> developer tools - vi or emacs like editor and plain text. The main
> problem of procedures maintained inside database is loss of outer
> formatting and outer comments. And you cannot to group procedures to
> modules. On the other hand - some history can be useful for all
> database objects - not only for stored procedures.
+ 1
also you are now managing your sql with the same tools you use for the
rest of the code. this is the way to go. the situation with views
argues even more for external management -- the original sql creating
the view is destroyed putting it in the database and it's not always
clear what the original intent was pulling it back out...
merlin
merlin