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@xxxxxxxxxxxxxx
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@xxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
