Re: [Pypgsql-users] Implementing Unicode

[Billy G. A. <Bil...@mu...>]

Adam Buraczewski wrote:
> 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:
>>>
>>> 	SET CLIENT_ENCODING TO 'LATIN2';
>>
>> I think it's a better idea that the connect method gets an optional
>> parameter client_encoding (used if and only if conversions to/from
>> Unicode are done), but the user has to issue a
>> "SET CLIENT_ENCODING TO 'whatever'" manually, too.
> 
> 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).

You have.  I have it implemented on my machine, but I've been swamped
with work related issues, leaving me little time for the fun stuff 
(pyPgSQL, etc.).  I will put the patch up on Friday for the transaction
level related changes.  I am also going to propose that transaction level
support be added to the next DB-API specification.

>                         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 'LAT
> I=
> N2';"],
> 	                     on_transaction_start =3D ["SET TRANSACTION ISOLATI
> O=
> 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 am leary of straying to far from the DB-API specification in the PgSQL
module (now the libpq module is a horse of a different color - it makes no
claim of DB-API compatiblity).

> 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.

Actually, with the newer versions of PostgreSQL, things that could not be
in a transaction are now transaction-safe.  For example, in version 7.1,
you can drop tables/indices within a transaction, but you couldn't in
previous versions.  Also, you can use another connection with autocommit on
to do the CREATEs, DROPs and ALTERs.
___________________________________________________________________________
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |