Re: [Pypgsql-users] Implementing Unicode

[Adam B. <ad...@po...>]

On Mon, Nov 26, 2001 at 02:24:13PM +0100, Gerhard H=E4ring wrote:
> > Then the PgSQL module should create a new Connection object, make a
> > connection to the database, and send:
> >=20
> > 	SET CLIENT_ENCODING TO 'LATIN2';
>=20
> I think it's a better idea that the connect method gets an optional par=
ameter
> client_encoding (used if and only if conversions to/from Unicode are do=
ne), but
> the user has to issue a "SET CLIENT_ENCODING TO 'whatever'" manually, t=
oo.

OK, it looks good for me.  As a programmer I don't like when a library
wrapper works behind the scenes and sends commands to a database
backend on its own.  However, it would be nice if PgSQL could send
automatically some commands to PostgreSQL backend on every session or
transaction start.  Lately I have convinced Billy (at least I hope so
;) ) to introduce a transaction isolation level support, which is
still absent from other Python interfaces for PostgreSQL (pyPgSQL is
the first, as I know).  I thought a bit about all that and a general
solution came to my mind: two lists (or, even better: dictionaires) of
strings.  One of them should be sent to PostgreSQL backend on session
start, the other just after every "BEGIN" command.  It would be then
possible to write something like this (an example, of course):

	conn =3D PgSQL.connect(database =3D "dbname,
	                     client_encoding =3D 'iso8859-2',
	                     on_session_start =3D ["SET CLIENT_ENCODING TO 'LATI=
N2';"],
	                     on_transaction_start =3D ["SET TRANSACTION ISOLATIO=
N LEVEL SERIALIZABLE;"])
	.
	.
	.
	conn.on_transaction_start.append("some SQL commands");

I agree that this idea could be not very bright ;)  Especially
isolation levels probably should be treated separately, due to their
special meaning.  However, such functionality should ease providing
future enhancements which will unlikely be demanded by a growing
community of pyPgSQL users :))

What do You think about this?

I'd like to add here that for me, DBI 2.0's cursors should be used
only for typical DQL statements, like SELECT, INSERT, UPDATE and
DELETE.  Other SQL commands (especially those which CREATE or DROP
something, ALTER a database structure, or SET some parameters)
shouldn't be used this way (since they usually cannot be issued during
a transaction, for instance), but DBI specification does not provide
any good solution for this.  I think that this all is because programs
which make use of DBI-compatible libraries should be portable (to
other DBMSes), and that a good, transaction-safe method of sending
these commands to PostgreSQL should be proposed here.

Regards,

--=20
Adam Buraczewski <ad...@po...> * Linux registered user #165585
GCS/TW d- s-:+>+:- a- C+++(++++) UL++++$ P++ L++++ E++ W+ N++ o? K? w--
O M- V- PS+ !PE Y PGP+ t+ 5 X+ R tv- b+ DI? D G++ e+++>++++ h r+>++ y?