Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/10/14 18:05, Mike Bayer wrote:
> 
> On Oct 7, 2014, at 8:29 AM, Ihar Hrachyshka <ihrachys at redhat.com>
> wrote:
> 
>> 
>> That said, I wonder how we're going to manage cases when those 
>> *global* settings for the whole server should be really limited
>> to specific databases. Isn't it better to enforce utf8 on service
>> side, since we already know that we always run against utf8
>> database?
> 
> I think whenever we do a ?CREATE DATABASE?, we should make sure the
> desired encodings are set up at that level.  I?ve seen lots of
> migration scripts that are listing through tables and setting each
> table individually to utf-8, and that?s less than ideal, though I
> suppose that?s more of a retroactive fix.
> 
>> 
>> Please let me clarify... Do you say that setting client encoding
>> on oslo.db side is actually ok? I haven't suggested to enforce
>> utf8 per column/table, though I guess we're already there.
> 
> The way we are setting client encoding now should be fine, if you
> could clarify what about that isn?t working for PG 8.4 that would
> be helpful.    IMHO especially on Postgresql we should be able to
> get away with not having it.   MySQLdb is not as nicely implemented
> as far as encoding (including the use_unicode speed issues) so it
> may be more necessary there.

PostgreSQL part is more for consistency with MySQL, but also to avoid
enforcing users to set utf8 globally for their SQL server. I think the
less we demand on configuration level the better (assuming we decided
on using utf8 globally for all our databases).

> 
> But yes what I really *dont* want is the encoding set up on every
> column definition, e.g. ?VARCHAR(20) CHARACTER SET ?utf-8??, that?s
> been suggested before and that would be terrible.   I don?t think
> Postgresql has quite the same thing available (only collation per
> column).
> 
>> 
>> Forgoing, again, means some users running with utf8 client
>> encoding, others without it. I strive towards consistency here,
>> that's why I try to find a way to set the setting for all clients
>> we support (and the question is *which* of those clients we
>> really support).
>> 
>> The thing that is not supported in psql < 9.1 is a connection
>> option added to libpq as of: 
>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=02e14562a806a96f38120c96421d39dfa7394192
>
>> 
> OK but that is just the connection parameter, when you pass
> client_encoding to SQLAlchemy?s psycopg2 dialect, the encoding is
> set using psycopg2?s set_client_encoding() method:
> http://initd.org/psycopg/docs/connection.html#connection.set_client_encoding.
> This ultimately emits ?SET client_encoding TO ?utf8?? on the
> connection:
> 
> conn_set_client_encoding ->
> https://github.com/psycopg/psycopg2/blob/master/psycopg/connection_int.c#L1188
>
>  pq_set_guc_locked ->
> https://github.com/psycopg/psycopg2/blob/master/psycopg/pqpath.c#L709
>
>  ?SET client_encoding TO <value>? is supported in all Postgresql
> versions, here?s 8.0:
> http://www.postgresql.org/docs/8.0/static/multibyte.html
> 
> So there?s no issue with Postgresql 8.2 here as far as client
> encoding, the libpq feature isn?t used for that.   Also, it
> defaults to the encoding that is set for the database (e.g. server
> side), so if we make sure CREATE DATABASE is emitted with the
> encoding, then we wouldn?t even need to set it (and perhaps we
> shouldn?t if the database is set to a different encoding).

As was revealed during IRC discussion with Mike, libpq
'client_encoding' and SQLAlchemy 'client_encoding' are different
beasts, and we have the latter into our possession when using libpq <
9.1, so it's better to use that one to avoid raising a minimum version
bar.

> 
> 
> 
> 
> 
> _______________________________________________ OpenStack-dev
> mailing list OpenStack-dev at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUNn5OAAoJEC5aWaUY1u57Y98H/2PGpZg4IeUKPqT2IGRtCOp3
Ln52cJ3ew/unL0n1JdBW/CAYuN2/c8jsFeWsFGG4P7zMrLh+AFUtmq/4xQShyLkM
YimaCzziN3beojVjPOKCYhMNNnS83pS7FIDXdEn/cdadFliiDX7m5rjMG40l9WOD
JFR5WfWPFrvura4VUDMjStmgFANxuxLboDy95xmdVomSL9m4Ms+/OZOPkcrV39Iu
H3scbIgZVEd8SZ1lpEQYMO4QXgSSfgEV+3efQbZADLYO8ig82a4h+nVN1079RAos
DfgxRdu1kK5NaPUFxbtbxhhTYbIuKRHf183tv6qJv6uPHgo06sLe5ie+is2q4LA=
=kSU1
-----END PGP SIGNATURE-----