support for client_encoding in PG

[Former user]

psycopg2 doesn't directly support client_encoding; it's not available as a keyword argument when connecting, but if using a DSN string, it's possible via: options='-c client_encoding=...'

In SA, it seems there's no way to get at this setting. Three suggestions: 1) Make "options" available through the URL system, connect_args, and/or as a keyword argument on create_engine. 2) Ditto above but exposing "client_encoding" as the argument and convert this to the options. 3) Use the value of encoding (as in the encoding used by SA for Unicode columns) for client_encoding, either implicitly (probably a bad idea) or explicitly with a True/False keyword argument on create_engine.

Thanks

[Mike Bayer]

can you point me to what "a DSN string with psycopg2" means , or are you talking about "dbname=test user=postgres password=secret" ? is that syntax part of the Postgresql client API ? also why not post this feature request to psycopg2 ? if they allow it as a **kw, you could just pass it using connect_args and no change would be needed here.

[Former user]

Replying to zzzeek:

can you point me to what "a DSN string with psycopg2" means , or are you talking about "dbname=test user=postgres password=secret" ? Yes is that syntax part of the Postgresql client API ? The syntax is part of libpq: http://www.postgresql.org/docs/8.4/static/libpq-connect.html also why not post this feature request to psycopg2 ? if they allow it as a **kw, you could just pass it using connect_args and no change would be needed here. As far as I'm aware, pyscopg is essentially a Python implementation of libpq, it'd be wrong or perhaps not possible for them to add this option. SA on the other hand is an abstraction of all this. Also, I don't know if other DBMS support something similar to client_encoding, but if they did, having a similar way to control it through SA would be a good thing.

[Mike Bayer]

Psycopg2's current public API for this apparently is the "set_client_encoding" method. This can be accessed right now using a PoolListener that runs on the connect() hook. A feature add on the SQLA side would make use of this method. This also seems to be what django does.

I'd prefer if psycopg2 could add client_encoding as a kw argument to its connect() method and I'd be interested to see what their rationale is if they reject such a feature (probably they'd say, "use set_client_encoding"). I don't want to bypass standard DBAPI and use a libpq calling convention directly.

Really, the usual "SQL_ASCII" default encoding should be removed from one's postgresql.conf file so that it defaults to the database's encoding. That's the best way to go here.

The "client encoding" idea is not necessarily portable to all backends and is too specific to DBAPI implementations and the target database in use for it to be worth adding a "generic" option. For example, DBAPIs that don't allow passing of Python unicode objects directly may or may not allow us to pass a bytestring that doesn't match the client encoding.

[Mike Bayer]

reading over psycopg2's docs it's clear they have all the "connection configuration" as methods after the fact, so this needs to be on our end, and that is in 5397d953650c3b7728e8285c55c32c5eeb687de9.

[Mike Bayer]

Removing milestone: 0.7.3 (automated comment)