Bit shift gives unexpected result

The result you're getting from FME is the correct result for a 64-bit integer (or an unsigned 32-bit integer), also called an arithmetic shift. The result you're getting from Postgres is due to a flipped sign, since the bit shift overflows the signed int32 datatype. This is commonly referred to as a logical shift.

For logical bit manipulations in FME I would recommend using Python, where you can force a specific datatype using the numpy libraries. Example:

>>> import numpy as np
>>> np.int32(255) << 24
-16777216

 To help understand the sign bit, consider the above compared to the same bit shift but using an unsigned 32-bit integer:

>>> np.uint32(255) << 24
4278190080

Way outside of my experience, as I've only messed about with bitshifts as part of advent of code but the result you get in FME (4278190080)  is as you would expect given what you are doing is the following

@Evaluate(255*@pow(2,24))

This is above the max for a 32 bit signed integer (you can see this in the error log in your workspace when you try and convert it using @int32)

Attribute(string)                 : `fme_expression_warnings{0}.attributeName' has value `shifted_24_as_int32'
Attribute(string)                 : `fme_expression_warnings{0}.message' has value `Failed to evaluate numeric expression '@int32(4278190080)'.  Result is set to null'
Attribute(string)                 : `fme_expression_warnings{0}.transformerName' has value `AttributeManager'

It looks like postgres is handling the overflow by wrapping around. I don't know how you can recreate this in FME. I know in python 255<<24 will give the result as per FME as the integers in python are not of a fixed bit width, you can use numpy to get the result you are seeing in postgres

import fme
import fmeobjects
import numpy as np
 
def processFeature(feature):
    feature.setAttribute("shifted_24_as_int32",int(np.left_shift(255,24)))