On 01/17/2015 06:01 PM, Berend Tober wrote:
> Thomas Kellerer wrote:
>> Berend Tober wrote on 17.01.2015 19:05:
>>> I often work with the output of pg_restore from a custom format dump
>>> file. ...
>>>
>>> Most often, I'm refactoring functions and so don't really want to
>>> drop the function but rather want to do a "create or replace
>>> function" ...
>>>
>>
>> To me this sounds as if you are doing it the wrong way round.
>
>
> Possibly. But if the revision control system and the production data
> base disagree, then which one do you believe?
I guess this depends on what you see as disagree. It is entirely
possible that the latest version(say testing) of code in the VCS is not
the same as the code in the production database. That is what tags are
for, a way to mark a point in time(development) to refer to. Having a
tag in the VCS that matches a state of the production database allows
one to make a comparison and be confident that the version control code
is the correct code. This of course requires an agreed upon method of
applying changes and tagging code. If you search -general you will find
previous discussions on this, for example:
http://www.postgresql.org/message-id/CAPTJ3=cJ5kB0Y9DUAA6rQh8yhqb5MssN1FvrFumGQLTOQ1+UPQ@mail.gmail.com
>
>
>>
>> To manage (refactor) your functions, you should have the current code
>> stored
>> in a version control system, update the code there an then apply it to
>> the
>> target database.
>>
>> Extracting the code from the database in order to do refactoring is
>> like disassembling a program each time you want to apply a bugfix.
>>
>> The code in the vcs would then contain the necessary "create or replace"
>> (btw you still need to drop the function if you change the parameters)
>>
>
>
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
