On Oct 6, 2014, at 9:56 AM, Ihar Hrachyshka <ihrac...@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.



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to