The MSVC compiler does not have the strcasecmp(x, y) function, which is a
case insensitve string compare function. Instead, MSVC has a similar function,
lstrcmpi(x, y). Modified config.h to use this function when building with
MSVC.
Functions conn_setup(), conn_get_isolation_level(), conn_set_transaction(),
conn_switch_isolation_level(), conn_set_client_encoding() reimplemented
using the pqpath funtitons.
Dropped analogous function in the connection, as it had to take the lock,
thus it was hard to build consistent pieces of functionality with it.
The aim of these function is to allow the connection to make a better use
of the pqpath functions instead of using PQexec for these small things.
Also, the functions are to be called with the connection lock: this makes
composing higher level functions using them easier.
The function is always called in the context of functions grabbing the
connection lock, so just use the same critical section instead of releasing
and re-acquiring it. It is not a problem as serious as the notifies process
(ticket #55) as the notices are a psycopg structure, not libpq. However the
change allows again processing notices/notifies in the same place,
which makes sense conceptually, plus we save some lock dance.
Notifies process access the connection, is not limited to the result, so
There is the possibility of loss of protocol sync in multithread programs.
Closes ticket #55.
Don't issue a SET TRANSACTION ISOLATION LEVEL at every begin: use PG's
GUC default, eventually set by set_transaction.
Dropped the last query at connection, yay!
Method set_isolation_level() and property isolation_level refactored using
the new structures, keeping the previous semantic.
Previously we only checked for the existence of the include files, but this
doesn't imply the presence of the module. Particularly true in restricted
environments such as virtualenv.
Closes ticket #53.
The encoding can be set by PGCLIENTENCODING, which may be an alternative
spelling. Bug reported by Peter Eisentraut.
At this point the idea of considering one of the random spellings such as
EUC_CN as somewhat "blessed" is debunked. So just store the cleaned-up
version of the encoding in the mapping table. Note that the cleaned-up
version was needed by the unicode adapter: this requirement has been
surpassed as the connection now contains a copy of the Python codec name
set whenever the client encoding is set.
PG 9.0 uses the hex format by default, and clients < 9.0 can't parse that
format, requiring client update and great care in what is linked at runtime,
and generally giving headache to users and transitively us.
