Just to expand a little on Roberto's response: The difficulty of porting depends (of course!) on which Oracle features are used in the code that you're porting. As mentioned in the porting guide, there is no completely straightforward way to port Oracle "connect by" statements, but the workarounds are not too painful.
I've been working on porting the bookmarks module, which uses a combination of row-level and statement-level triggers to do a second set of changes to a table once the first changes are complete. (I can't remember the correct term for this, but it has to do with the fact that you can't do certain things to a "mutating table".) Since postgres doesn't have statement-level triggers, nor, I think, a way to store an array of values for a later procedure to process, you can't do some of the things that you can with Oracle stored procedures. The workaround for the problem at hand seems to be to move some of the logic out of stored procedures and into the tcl program that calls the update. (If I'm wrong here, I'd love to know.) This is not beautiful, since you may be stuck writing the same workaround in many places.
Also, postgres seems to have bugs or idiosyncracies that make it finicky about syntax. I had some problems concatenating strings: It won't concatenate a null value to a string in a stored procedure, but it will in a regular sql statement. It wants the two strings to be cast as the same type. Syntax for stored procedures took a certain amount of trial and error. This will become easier, I suppose, when more documentation with detailed syntax examples appears.
All in all, it's a lot easier than figuring out how to install and administer a production Oracle server. >:0
Best,
