Open Stack

On Oct 6, 2014, at 9:56 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> >
> > But we can do better. We should also enforce utf8 on client side,
> > so that there is no way to run with a different encoding, and so
> > that we may get rid of additional options in sql connection
> > strings. I've sent a patch for oslo.db [4] to do just that.

i would recommend that we definitely do *not* set explicit client encodings on all columns, and go with the most minimal approach for whatever the target database is.    For example, with Postgresql 8.4, utf-8 is not an issue so long as client_encoding is set within postgresql.conf.    I’ve had this kind of discussion many times in the past with folks who are trying to “protect” some subset of users that don’t have this setting in their conf file, either because they installed from an OSX package or some other weird reason, and generally I’m not buying it.    There’s no need to build tremendous verbosity and fine-grained specificity throughout a system in order to appease very narrow edge cases like this.   It’s not just about potential performance problems, it’s also just a schema and code management issue, in that it is complexity that IMHO is just not needed.

For this reason I’m pretty ambivalent overall about any kind of utf-8 hardcoding within the application connection logic.  IMHO this should be handled at the configurational layer as much as possible.  Though as long as it’s just an application time setting, and not something hardwired throughout the schema (implying we now have to *rely* upon UTF-8 encoding explicitly for all columns everywhere…and then what happens if we are on some target database that doesn’t quite do things the same way, e.g. DB2, oracle, others?), it’s not *too* big of a deal for me if it solves some problems right now.

short answer, there should be no need to drop PG8.X support for this reason.   If the client encoding setting is something we want hardcoded in the app layer and it fails for those versions (which I’m not familiar with? what is the thing that is not actually supported prior to libpq 9.1 ?  psycopg2’s set_client_encoding, really?   this doesn’t sound familiar two me), we can detect that and forego the setting - sqlalchemy dialect has server_version_info for this reason.