As for your first question;
Business logic is most commonly best kept in a business logic space in your application layer and not in connection with the data itself. It is the multi tiered approach to limit complexity and follow various code "best practices".
The database is there to keep your data safe, and basically - that is what you should do with it.
One reason for this is that business logic often can become quite complex, it is volatile and will change more often than the data itself will change (Product data is product data, but how to treat the data, calculate and display, changes more often, for example).
Another reason is that business logics complexity often means that you'll perform operations, and those operations will often be much faster to perform in a code layer. Data base systems are heavily optimized for querying (relational models for set based queries etc) and not for doing complex calculations and manipulations.
Also the maintainability is often much higher in a code/application layer. For many teams it's easier to track changes in an application code layer as many seem to not set up source control for a database. Also, with a code layer you get better type handling, many more programming tools and techniques to go with problem solving.
So, the database is good at handling data, storing and querying (well, it's good if done "correctly") and application code layers are good at application work, so the general rule of thumb, is to keep the business logic in the business logic space of the application.
Granted some database servers try to merge these two spheres of systems - but the rule of thumb is there for a reason.
Now, all these rules of thumbs aside, then there are situations where business logic do 'creep' into the database and occasionally are better kept in the database.
For example with import/export/migration functions kept fully in the database to avoid pulling a lot of data into a code layer to push it down again. Then often you'll have some minor business rules in the database in connection with a query, such as an Active flag might be changed from a true/false value to a Yes/No value in an export query, because that's what "they" want to receive on the other end. But these are generally minor rules.
So as with all things you'll need to evaluate your own requirements for the system/project; analyze what the data is and how it is used; and then after that you can design your system and where to handle data modifications.
As for your second question, it sounds like you'll need some form of source control system, just like you would have with application code. I'm unsure which systems function for postgresql - but I bet there are some out there. Some do it by scripting the database functions, tables and similar into a system like SVN so changes can be tracked