Postgres using replace function; Postgres replacing phrase in an XML-typed column;

I wanted to replace column content '{ApplicationVersion}' with '{RegularMessage}' string. Postgres syntax seemed a little bit strange to me (because of the XMLPARSE) so I’m writing the solution here. As it turned I had to cast my content argument to text first as it was an XML-typed column - there is no automatic casting. If you forget to that the error pops up which suggests there is no replace function referenced but it actually means that there is no replace function with such arguments so you should cast your arguments:

ERROR: function replace(xml, unknown, unknown) does not exist

update message
set content = XMLPARSE(
DOCUMENT replace(text(content),'{ApplicationVersion}','{RegularMessage}')
)
where type = 'RegularMessage';

where content is the xml-typed column.

XMLPARSE can have DOCUMENT or CONTENT as arguments and you need to write one of the two keywords before the actual column name:

XMLPARSE (DOCUMENT '<?xml version="1.0"?><book><title>Manual</title></book>');

or

XMLPARSE (CONTENT 'abc<foo>bar</foo><bar>foo</bar>');

GIT good practices; What to remember when coming from SVN; SVN to GIT tutorial

When working with a distributed repository system one needs to remember that it is slightly different from SVN and CVS repositories. I will put most aspects in points for easy remembering.

1. Your LOCAL commit time/order is remembered when pushing your changes. So if you commit changes on master and then try pulling and pushing it will create a nasty “divide and merge” track on master. It looks like this:
   
   
   
   To prevent this behavior always do REBASE instead of pull when syncing with the distributed repository.
   
   Rebase in TortoiseGit is available from rightClick->Git sync->Fetch&Rebase
   
2. If possible work on your LOCAL branch. For example, when your main branch is called “master”, create a branch called “localMaster” and commit changes to this branch. When the time comes to push your changes you will switch to “master”, pull the changes. Then switch back to “localMaster”, rebase localMaster in position to master to include all the changes which have been made on master and resolve any conflicts. Then switch to “master”, merge master from “localMaster” to include changes from “localMaster” in “master”. In the end you just push your “master” branch.

 

GIT good practices – using “master” and “localMaster” branches.

• You clone the repository from source. And create your “localMaster” branch. So you have: “origin/master”, “origin/HEAD”, “master” and “localMaster”.
  
  
  
• commit changes to “localMaster” branch
  
  
  
• Switch back to “master” branch and pull changes from repo
  
  
  
• switch to “localMaster” and do a rebase with “master”. In this way all the changes which have been pulled to master will be reflected in “localMaster” branch
  
  
  
• this is how it looks “as a pure concept” after the rebase. You need to resolve any conflicts that can occur during this process.
  
  
  
• switch to “master” branch and merge changes from “localMaster” to reflect commits made in “localMaster” to “master” branch
  
  
  
• now that you have merged “master” and “localMaster” you can switch to “master” and push your changes so that others can see your commits.
  
  
  

I hope this is helpful.