bytea::text sqlCreator differs from Pgadmin

FME does not know what to do with a bytea sequence, you'll have to cast it to something else before FME gets to it. 

Have you tried something like:

select encode(('\x5545734...141'::bytea), 'base64') as test

If it works as intended, it should be possible to use a BinaryDecoder set to "Base64" to decode the binary.

Thanks for your response, but i had already tried this. The string i put into the bytea is already encoded to base64 and looks like (when i inspect when inserting it into our database)

'UEsDBBQAAAAIAGNzKk55pjtIWQAAAHsAAAAKAAAAMXJlY2VwLnJjcCXFywmAMBRE0b1gD1OBvPyeSTVBVNyoAUFRq3ckDGfufmAfthl3Hks58NQM15JfwVS2vJ5YT0OWHHkKpNRTpNQ2gugTjBrvAmzSKALpNIZkDSwEqrw65/98UEsBAj8AFAAAAAgAY3MqTnmmO0hZAAAAewAAAAoAJAAAAAAAAAAgAAAAAAAAADFyZWNlcC5yY3AKACAAAAAAAAEAGADIVDgt6KjUARvYNC3oqNQBG9g0Leio1AFQSwUGAAAAAAEAAQBcAAAAgQAAAAAA'

and when i use your solution i get a different string. (probably double encoded)

The problem is that i expect to get the same result from Postgres (pgadmin) aswel with SqlExecutor.

And I found the problem. Appearantly Postgres has a bytea ouput setting that isn't used by FME sqlExecutor. So i added :

set bytea_output = 'escape';

select calculation_point_content::text, calculation_point_content_text from am_calculation_point_sets

where calculation_point_set_code = '1recep'

And now i get the desired results.