Commented by: @asfernandes

???????

Commented by: @WarmBooter

For this, gbak would need to change the metadata of the database. Even if it was able to do that, what should gbak do if the original charset has characters that are not available in the destination charset?

Commented by: Sean Leyne (seanleyne)

As Carlos pointed out, there are several issues which make the "auto-magic" changing the charset of a database very difficult, if not impossible.

Any update on this?

I'd say it is unlikely to ever get implemented for the reasons provided earlier. Personally, I think this issue should be closed, what do you think @dyemanov ?

I can see two cases it could be useful and unlikely to cause any errors:

1. Converting NONE database into a proper charset (data is actually stored in)
2. Migrating from WIN/ISO-something into UTF8

Perhaps they will be 98% of all cases. And migrating via a script is a PITA for big databases.

That said, I also see problems. What if different fields have different charsets defined, should all of them be changed? Should we ignore OCTETS fields while converting data? What if the longer (in bytes) field definition would prevent some existing indices from being created? _charset literal prefixes inside PSQL routines cannot be migrated to another charset. Too many border cases to worry about, IMO. So perhaps we should really close it as undoable in general.

It may be done in conjunction with "--data-only" switch by setting corresponding connection charset but it would be better to create a separate utility ("exp"?) with wider set of options for exporting/importing.

Improved ISQL extract (which separation of triggers and indexes) plus GBAK data-only may be useful for that and other cases.