Am 07.05.2015 um 18:17 schrieb David Boyes:
> I also think you'll find that your backup load is much smaller with
> attachments outside the database -- every time you change the
> database, the whole file has to get dumped (unless you have a fairly
> smart backup system and are doing table-level b
> LONGBLOBs are just streams of bytes. Intel or not (endianness) should not
> matter when you fetch and store the data using database methods.
> BLOBs are good for storing binary objects such as attachments or emails that
> you want to keep in their original encoding. Everything else should be stor
Am 07.05.2015 um 15:02 schrieb David Boyes:
>> These are handled differently by OTRS - for
>> databases other than MySQL, OTRS stores them in BASE64 encoding. The
>> conversion can be done with Postgres using encode(column, 'base64').
>
I'd rather see MySQL use base64 too. All the world isn't Int
> These are handled differently by OTRS - for
> databases other than MySQL, OTRS stores them in BASE64 encoding. The
> conversion can be done with Postgres using encode(column, 'base64').
I'd rather see MySQL use base64 too. All the world isn't Intel-based, and at
least base64 is not ambiguous wh
When trying to migrate our OTRS database from MySQL to PostgreSQL, I
noticed that the MySQL database uses LONGBLOBs in several places, which
are binary objects, while on the other hand, OTRS creates TEXT columns
for these columns when using PostgreSQL, which is a character type, not
binary. Sim
