pypgsql-users — Discussion list for the pyPgSQL user community.

Re: [Pypgsql-users] segfaults

[Craig M. <cr...@th...>]

On Tue, 2003-04-22 at 16:16, Gerhard H=E4ring wrote:

> Ouch. This isn't useful :-(
>=20
> To debug these kind of crashes we'll need to add diagnostic output to=20
> the C sources. Could you please apply the attached patch to=20
> libpqmodule.c (the patch is against pyPgSQL 2.3) and post the output of=20
> a "from pyPgSQL import libpq" ?
>=20
With the patch compiled in, and using a this file test.py containing:

#!/usr/bin/python

from pyPgSQL import libpq

I get this output:

laptop test # python test.py=20
FILE: libpqmodule.c, LINE: 950
FILE: libpqmodule.c, LINE: 952
FILE: libpqmodule.c, LINE: 954
FILE: libpqmodule.c, LINE: 956
FILE: libpqmodule.c, LINE: 963
FILE: libpqmodule.c, LINE: 965
FILE: libpqmodule.c, LINE: 967
FILE: libpqmodule.c, LINE: 969
FILE: libpqmodule.c, LINE: 971
FILE: libpqmodule.c, LINE: 973
FILE: libpqmodule.c, LINE: 975
FILE: libpqmodule.c, LINE: 980
FILE: libpqmodule.c, LINE: 982
FILE: libpqmodule.c, LINE: 1101
FILE: libpqmodule.c, LINE: 1162

Regards
Craig


--=20
Craig Main
RHCE
ST Solutions
Cell: 082-323-4670
Home Tel: 011-760-1900
AIM: SATuxman; ICQ: 75815570

Re: [Pypgsql-users] Error: No such attribute or function 'attisdropped'

[<gh...@gh...>]

Xueying Ni wrote:
> Hi, Gerhard:
> 
> Here is the traceback I can offer so far:
> 
> try:    db=pg.DB('xxx', 'localhost', 5433, '', '', 'xxx', 'xxx')
> 
> except:
>         print sys.exc_type, sys.exc_value
> 
> _pg.error ERROR: No such attribute or function 'attisdropped'
> 
> Any ideas? Are there other ways to show more detail traceback of the 
> error?

Did you notice you're on the *pyPgSQL* list? This looks suspiciously 
like a snippet of code using *PyGreSQL*.

The PyGreSQL list is over there:

http://mail.vex.net:99/mailman/listinfo/pygresql

To my knowledge there is no released version of PyGreSQL that supports 
PostgreSQL 7.3. One more reason to switch :-)

-- Gerhard

Re: [Pypgsql-users] segfaults

[<gh...@gh...>]

Craig Main wrote:
> On Sat, 2003-04-19 at 11:37, Gerhard Häring wrote:> 
>>Craig Main wrote:
>>>Hi all,
>>>
>>>Can anyone point me in the right direction for solving this? I am
>>>running Gentoo. Running python test/PgSQLTestCases.py gives a segfault.
>>>I have narrowed it down to the "from pyPgSQL import PgSQL" line.
>>>
>>>Any ideas?
>>
>>Does "from pyPgSQL import libpq" segfault already, too?
> 
> yes
> 
> This is what I get in the backtrace:
> 
> (gdb) core core
> Core was generated by `python PgSQLTestCases.py'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x402a6637 in ?? ()
> #0  0x402a6637 in ?? ()
> #1  0x402aa7dc in ?? ()
> [...]

Ouch. This isn't useful :-(

To debug these kind of crashes we'll need to add diagnostic output to 
the C sources. Could you please apply the attached patch to 
libpqmodule.c (the patch is against pyPgSQL 2.3) and post the output of 
a "from pyPgSQL import libpq" ?

Thanks,

-- Gerhard

Re: [Pypgsql-users] segfaults

[Craig M. <cr...@th...>]

On Sat, 2003-04-19 at 11:37, Gerhard H=E4ring wrote:
> Craig Main wrote:
> > Hi all,
> >=20
> > Can anyone point me in the right direction for solving this? I am
> > running Gentoo. Running python test/PgSQLTestCases.py gives a segfault.
> > I have narrowed it down to the "from pyPgSQL import PgSQL" line.
> >=20
> > Any ideas?
>=20
> Does "from pyPgSQL import libpq" segfault already, too?
>=20
yes

> Can you try the following:
>=20
> 1) Build pyPgSQL with debugging info:
>=20
> $ python setup.py build --debug
>=20
> 2) Under bash, enter: "ulimit -c unlimited"
>=20
> 3) Run the test suite. You'll get a core file (let's suppose it's called=20
> python.core).
>=20
> 4) Fire up gdb and load the core file, then show the backtrace:
> gdb> core python.core
> gdb> backtrace
>=20
> Do you see anything that makes sense there? Could you post the traceback?
>=20
This is what I get in the backtrace:

(gdb) core core
Core was generated by `python PgSQLTestCases.py'.
Program terminated with signal 11, Segmentation fault.
#0  0x402a6637 in ?? ()
#0  0x402a6637 in ?? ()
#1  0x402aa7dc in ?? ()
#2  0x080dd21d in ?? ()
#3  0x08078bb2 in ?? ()
#4  0x08079569 in ?? ()
#5  0x0807baa7 in ?? ()
#6  0x08095896 in ?? ()
#7  0x08097ff0 in ?? ()
#8  0x0809604b in ?? ()
#9  0x08096e73 in ?? ()
#10 0x08096a09 in ?? ()
#11 0x08098518 in ?? ()
#12 0x080979ec in ?? ()
#13 0x080df356 in ?? ()
#14 0x080dd21d in ?? ()
#15 0x080bca99 in ?? ()
#16 0x0807a2e5 in ?? ()
#17 0x080785f1 in ?? ()
#18 0x08079569 in ?? ()
#19 0x0807baa7 in ?? ()
#20 0x08095896 in ?? ()
#21 0x08097ff0 in ?? ()
#22 0x0809604b in ?? ()
#23 0x0809837c in ?? ()
#24 0x080961a2 in ?? ()
#25 0x08096e73 in ?? ()
#26 0x08096c63 in ?? ()
#27 0x08098598 in ?? ()
#28 0x080979ec in ?? ()
#29 0x080df356 in ?? ()
#30 0x080dd21d in ?? ()
#31 0x080bca99 in ?? ()
#32 0x0807a2e5 in ?? ()
#33 0x080785f1 in ?? ()
#34 0x08079569 in ?? ()
#35 0x0807baa7 in ?? ()
#36 0x08095896 in ?? ()
#37 0x08097ff0 in ?? ()
#38 0x0809604b in ?? ()
#39 0x08096e73 in ?? ()
#40 0x08096c63 in ?? ()
#41 0x08098598 in ?? ()
#42 0x080979ec in ?? ()
#43 0x080df356 in ?? ()
#44 0x080dd21d in ?? ()
#45 0x080bca99 in ?? ()
#46 0x0807a2e5 in ?? ()
#47 0x080785f1 in ?? ()
#48 0x08079569 in ?? ()
#49 0x0807baa7 in ?? ()
#50 0x080a085b in ?? ()
#51 0x080a006d in ?? ()
#52 0x08053460 in ?? ()
#53 0x08052fcb in ?? ()
#54 0x4018c7a7 in ?? ()

TIA
Craig


> -- Gerhard
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pypgsql-users mailing list
> Pyp...@li...
> https://lists.sourceforge.net/lists/listinfo/pypgsql-users
--=20
Craig Main
RHCE
ST Solutions
Cell: 082-323-4670
Home Tel: 011-760-1900
AIM: SATuxman; ICQ: 75815570

Re: [Pypgsql-users] Error: No such attribute or function 'attisdropped'

[Xueying Ni <xy...@eb...>]

Hi, Gerhard:

Here is the traceback I can offer so far:

try:    db=3Dpg.DB('xxx', 'localhost', 5433, '', '', 'xxx', 'xxx')

except:
        print sys.exc_type, sys.exc_value

_pg.error ERROR: No such attribute or function 'attisdropped'

Any ideas? Are there other ways to show more detail traceback of the=20
error?

Xueying

On Wed, 9 Apr 2003, Gerhard H=E4ring wrote:

> Xueying Ni wrote:
> > Dear pyGreSQL experts:
>=20
> Hell, no! ;-)
>=20
> > Since my web hosting company announced adding the addition of Postgre=
SQL=20
> > 7.3.2 on all operational servers, my web database application can not=
 be=20
> > accessed from the web browser anymore.
> >=20
> > The following pg.error message occured when trying to connect to the=20
> > database from web:
> >=20
> > Error: No such attribute or function 'attisdropped'.=20
> >=20
> > The web applcation is  running pyPgSQL 2.3 on Red Hat Linux 7.1 apach=
e=20
> > server, PostgreSQL 7.2, and  Python 2.1. I have a non-superuser Postg=
reSQL=20
> > account.=20
> >=20
> > Any ideas about it?
>=20
> Do you have a traceback to offer?
>=20
> -- Gerhard
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debu=
gger=20
> for complex code. Debugging C/C++ programs can leave you feeling lost a=
nd=20
> disoriented. TotalView can help you find your way. Available on major U=
NIX=20
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Pypgsql-users mailing list
> Pyp...@li...
> https://lists.sourceforge.net/lists/listinfo/pypgsql-users
>=20

Re: [Pypgsql-users] Support for optional scroll method.

[Billy G. A. <bal...@wi...>]

Benjamin Scherrey wrote:

>The DB-API 2.0 PEP specifies an optional mechanism for handling cursors and providing forward 
>and backward iteration via the cursor.scroll() method. I was curious as to whether or not this was 
>something coming for PyPgSQL and, until then, what would be a good workaround for going 
>backwards in a cursor.
>
>	many thanx,
>
>		Ben Scherrey
>
Yes they will be added to pyPgSQL (If you want to supply a patch, I 
won't object :-)  ).
The cursor object has a rewind method, which will rewind the cursor back 
to the beginning.

Your can also execute a query in the form:

 cursor.execute('MOVE BACKWARD XXX IN "%s"' % cursor.name) or
 cursor.execute('MOVE FORWARD XXX IN "%s"' % cursor.name)

[If you would like to supply a patch to implement .scroll(), you can use 
.rewind() as a model]

I hope this helps.

>  
>

[Pypgsql-users] Support for optional scroll method.

[Benjamin S. <sch...@pr...>]

The DB-API 2.0 PEP specifies an optional mechanism for handling cursors and providing forward 
and backward iteration via the cursor.scroll() method. I was curious as to whether or not this was 
something coming for PyPgSQL and, until then, what would be a good workaround for going 
backwards in a cursor.

	many thanx,

		Ben Scherrey

Re: [Pypgsql-users] segfaults

[<gh...@gh...>]

Craig Main wrote:
> Hi all,
> 
> Can anyone point me in the right direction for solving this? I am
> running Gentoo. Running python test/PgSQLTestCases.py gives a segfault.
> I have narrowed it down to the "from pyPgSQL import PgSQL" line.
> 
> Any ideas?

Does "from pyPgSQL import libpq" segfault already, too?

Can you try the following:

1) Build pyPgSQL with debugging info:

$ python setup.py build --debug

2) Under bash, enter: "ulimit -c unlimited"

3) Run the test suite. You'll get a core file (let's suppose it's called 
python.core).

4) Fire up gdb and load the core file, then show the backtrace:
gdb> core python.core
gdb> backtrace

Do you see anything that makes sense there? Could you post the traceback?

-- Gerhard

[Pypgsql-users] segfaults

[Craig M. <cr...@th...>]

Hi all,

Can anyone point me in the right direction for solving this? I am
running Gentoo. Running python test/PgSQLTestCases.py gives a segfault.
I have narrowed it down to the "from pyPgSQL import PgSQL" line.

Any ideas?

TIA
Craig
--
Craig Main
RHCE
ST Solutions
Cell: 082-323-4670
Home Tel: 011-760-1900
AIM: SATuxman; ICQ: 75815570

Re: [Pypgsql-users] Prepared Statements

[Ben L. <pyp...@zu...>]

Thank-very much for your help Gerhard and Karsten. I've just implemented the 
code suggested by Gerhard and it does exactly what I require.

It can see it should work with the Bytea stuff but I need to make some more 
changes to by app before I can test that.

Thanks again,

Ben.

P.S. If anyone is writing web apps I can highly recommend the combination 
Postgres, pyPgSQL and mod_python. It runs extremely quickly on four year old 
hardware.


On Monday 14 Apr 2003 2:42 pm, Karsten Hilbert wrote:
> > sql = "UPDATE %s SET " % bizobj.table
> > for field in bizobj.fields:
> > 	sql += "%s = '%s' " % (field.name, field.value)
> > sql += ";"
>
> I always had to use
>
> sql = "update table set field=%s;"
> cursor.execute(sql, PgBytea(value))
>
> with bytea data. It didn't work the other way.
>
> Note that it is permissible to have more formatters in a
> string than there are values to replace them. Just be careful
> to replace the right ones at the right time.
>
> > TypeError: query() argument 1 must be string without null bytes, not str
>
> '%s' % value will in effect insert str(value) which isn't
> right for ByteA.
>
> Karsten

Re: [Pypgsql-users] Prepared Statements

[Karsten H. <Kar...@gm...>]

> sql = "UPDATE %s SET " % bizobj.table
> for field in bizobj.fields:
> 	sql += "%s = '%s' " % (field.name, field.value)
> sql += ";"
I always had to use

sql = "update table set field=%s;"
cursor.execute(sql, PgBytea(value))

with bytea data. It didn't work the other way.

Note that it is permissible to have more formatters in a
string than there are values to replace them. Just be careful
to replace the right ones at the right time.

> TypeError: query() argument 1 must be string without null bytes, not str
'%s' % value will in effect insert str(value) which isn't
right for ByteA.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Re: [Pypgsql-users] Prepared Statements

[Gerhard H. <gh...@gh...>]

Ben Lamb wrote:
> Exactly.
> 
> I'm writing an app with a web-based interface and I've made myself a load of 
> objects that all inherit from a base class called Field. I can call a method 
> and the Field will return HTML code to edit itself, if it is a DateField that 
> will consist of some listboxes, for booleans a checkbox.
> 
> I then have some business objects which carry a list of fields. When I tell 
> the business object to write itself to the database it constructs a query 
> along of the lines of:
> 
> sql = "UPDATE %s SET " % bizobj.table
> for field in bizobj.fields:
> 	sql += "%s = '%s' " % (field.name, field.value)
> sql += ";"
> 
> When I accept input from the web I don't want someone attempting to inject 
> their own SQL, nor do I want the query to fail if they type a character that 
> needs escaping e.g. 
> 
> I could write a function to check all this myself but I'd rather use what's in 
> pyPgSQL. [...]

It works if you separate these two concerns:

1) Building the SQL string with placeholders
2) Telling the DB-API module which query to execute, and with which 
parameters

The trick with using Python's quoting is that if you double the percent 
sign, it is kept after quoting with the % operator. I confess that the 
mass of % signs below might be confusing at first sight ;-)

Attached is a working example of dynamically constructing a SQL string, 
while still using pyPgSQL's quoting of the various types. Note that 
pyPgSQL can handle a dictionary as the second parameter to cursor.execute.

-- Gerhard

Re: [Pypgsql-users] Prepared Statements

[Ben L. <pyp...@zu...>]

Exactly.

I'm writing an app with a web-based interface and I've made myself a load of 
objects that all inherit from a base class called Field. I can call a method 
and the Field will return HTML code to edit itself, if it is a DateField that 
will consist of some listboxes, for booleans a checkbox.

I then have some business objects which carry a list of fields. When I tell 
the business object to write itself to the database it constructs a query 
along of the lines of:

sql = "UPDATE %s SET " % bizobj.table
for field in bizobj.fields:
	sql += "%s = '%s' " % (field.name, field.value)
sql += ";"

When I accept input from the web I don't want someone attempting to inject 
their own SQL, nor do I want the query to fail if they type a character that 
needs escaping e.g. '

I could write a function to check all this myself but I'd rather use what's in 
pyPgSQL.

ByteA fields are causing me problems using the approach above, I get the 
following error when field.value is contains PgSQL.PgBytea( binary_data):

TypeError: query() argument 1 must be string without null bytes, not str

I'm not sure how to solve it.

Thanks,

Ben.



On Monday 14 Apr 2003 12:22 pm, Karsten Hilbert wrote:
> Ben,
>
> you mean like
>
> sql = "SELECT wibble FROM wobble "
>
> if foo:
>     sql += " WHERE somefield = '%s';" % some_variable
> elif bar:
>     sql += " WHERE someotherfield = '%s';" % some_other_variable
>
> ?
>
> Karsten

Re: [Pypgsql-users] Prepared Statements

[Karsten H. <Kar...@gm...>]

Ben,

you mean like

sql = "SELECT wibble FROM wobble "

if foo:
    sql += " WHERE somefield = '%s';" % some_variable
elif bar:
    sql += " WHERE someotherfield = '%s';" % some_other_variable

?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

[Pypgsql-users] Prepared Statements

[Ben L. <be...@zu...>]

Hi,

In my program I was building SQL queries in this fashion:

sql = "SELECT wibble FROM wobble "
sql += " WHERE somefield = '%s';" % some_variable
cursor.execute(sql)

Doing it properely gives me flexibility, especially with regard to quoting 
bytea values, and security, viz:

cursor.execute("SELECT wibble FROM wobble WHERE somefield = %s;", 
some_variable)

However, some of my SQL statements get rather complicated, is there a way of 
building one up gradually then passing it to cursor.execute()? Sometimes I 
need to include/exclude entire subclauses.

Thanks,

Ben Lamb.

Re: [Pypgsql-users] Error: No such attribute or function 'attisdropped'

[<li...@gh...>]

Xueying Ni wrote:
> Dear pyGreSQL experts:

Hell, no! ;-)

> Since my web hosting company announced adding the addition of PostgreSQL 
> 7.3.2 on all operational servers, my web database application can not be 
> accessed from the web browser anymore.
> 
> The following pg.error message occured when trying to connect to the 
> database from web:
> 
> Error: No such attribute or function 'attisdropped'. 
> 
> The web applcation is  running pyPgSQL 2.3 on Red Hat Linux 7.1 apache 
> server, PostgreSQL 7.2, and  Python 2.1. I have a non-superuser PostgreSQL 
> account. 
> 
> Any ideas about it?

Do you have a traceback to offer?

-- Gerhard

[Pypgsql-users] Error: No such attribute or function 'attisdropped'

[Xueying Ni <xy...@eb...>]

Dear pyGreSQL experts:

Since my web hosting company announced adding the addition of PostgreSQL 
7.3.2 on all operational servers, my web database application can not be 
accessed from the web browser anymore.

The following pg.error message occured when trying to connect to the 
database from web:

Error: No such attribute or function 'attisdropped'. 

The web applcation is  running pyPgSQL 2.3 on Red Hat Linux 7.1 apache 
server, PostgreSQL 7.2, and  Python 2.1. I have a non-superuser PostgreSQL 
account. 

Any ideas about it?

Regards,

Xueying Ni

[Pypgsql-users] Re: PySqlite for the Python 2.3a

[<li...@gh...>]

[Spamming all involved lists, too]

Driver, David wrote:
> "I don't plan to make an "official" package for 2.3 alphas, but I could
> provide an "unofficial" one."
> 
> At this point I would gladly use an unofficial install. [...]

David,

I've now uploaded *unsupported* binaries for Python 2.3 alpha2 on 
Windows of the following to my homepage:

- CVS snapshot of PySQLite as of today
- CVS snapshot of pyPgSQL as of today
- build of egenix mxDateTime 2.1beta5 (zip file)

You can grab the goodies at:

http://ghaering.de/python/unsupported/

"Unspported" means I'm only interested in bug reports against released 
versions of Python (2.1.x or 2.2.x) or PySQLite/pyPgSQL in combination 
with a released mxDateTime version. Bugs in the combination of a 
pre-release Python, pyPgSQL/PySQLite *and* mxDateTime are just too hard 
to track.

Otherwise, have fun playing with the new 2.3 features :-)

-- Gerhard

Re: [Pypgsql-users] Trouble supporting mixed case entities.

[Gerhard <gh...@gh...>]

* Benjamin Scherrey <sch...@pr...> [2003-03-31 19:35 -0500]:
> Bah! Didn't send correct code... here's the corrected code that demonstrates the problem:
>         print res['"FName"']
>         print res['"LName"']

print res['FName'], res['LName'], res.FName, res.LName

all work :)

Gerhard
-- 
mail:   gh...@gh...
web:    http://ghaering.de/

Re: [Pypgsql-users] Trouble supporting mixed case entities.

[Benjamin S. <sch...@pr...>]

Ah!! Once again I outsmarted myself by insisting on quoting out the quotes... this python's stuff too 
smart for my own good... :-)

	many thanx,

		Ben Scherrey

3/31/2003 7:35:44 PM, Gerhard Häring <gh...@gh...> wrote:

>* Benjamin Scherrey <sch...@pr...> [2003-03-31 18:45 -0500]:
>> [...]
>>         cstmt = r"""create table "Test" ( "FName" varchar(20), "LName" varchar(20) )"""
>>         istmt = r"""insert into "Test" values ( 'Benjamin', 'Scherrey' )"""
>>         sstmt = r"""select "FName", "LName" from "Test" """
>> [...]
>>     
>>     print res["fname"]
>>     print res["lname"]
>
>If you use quotes around SQL identifiers, case matters. Try:
>
>print res["FName"], res["LName"]
>
>or even:
>
>print res.FName, res.LName
>
>Gerhard

Re: [Pypgsql-users] Trouble supporting mixed case entities.

[Gerhard <gh...@gh...>]

* Benjamin Scherrey <sch...@pr...> [2003-03-31 18:45 -0500]:
> [...]
>         cstmt = r"""create table "Test" ( "FName" varchar(20), "LName" varchar(20) )"""
>         istmt = r"""insert into "Test" values ( 'Benjamin', 'Scherrey' )"""
>         sstmt = r"""select "FName", "LName" from "Test" """
> [...]
>     
>     print res["fname"]
>     print res["lname"]

If you use quotes around SQL identifiers, case matters. Try:

print res["FName"], res["LName"]

or even:

print res.FName, res.LName

Gerhard
-- 
mail:   gh...@gh...
web:    http://ghaering.de/

Re: [Pypgsql-users] Trouble supporting mixed case entities.

[Benjamin S. <sch...@pr...>]

Bah! Didn't send correct code... here's the corrected code that demonstrates the problem:

------------------------------
from pyPgSQL import PgSQL

if __name__ == '__main__':
    src = PgSQL.connect( user="xxx", password="xxx", host="xxx", database="xxx" );
    cur = src.cursor()

    cstmt = ""
    sstmt = ""
    istmt = ""

    # Change this to demonstrate problem with mixed case...
    mixed = 0

    if not mixed:   
        cstmt = r"""create table test ( fname varchar(20), lname varchar(20) )"""
        istmt = r"""insert into test values ( 'Benjamin', 'Scherrey' )"""
        sstmt = r"""select fname, lname from test"""

    else:
        cstmt = r"""create table "Test" ( "FName" varchar(20), "LName" varchar(20) )"""
        istmt = r"""insert into "Test" values ( 'Benjamin', 'Scherrey' )"""
        sstmt = r"""select "FName", "LName" from "Test" """


    print cstmt
    cur.execute( cstmt )

    print istmt
    cur.execute( istmt )

    print sstmt
    cur.execute( sstmt )

    res = cur.fetchone()

    if not mixed:
        print res["fname"]
        print res["lname"]
    else:
        print res['"FName"']
        print res['"LName"']
    
    cur.close()
    src.close() 

[Pypgsql-users] Trouble supporting mixed case entities.

[Benjamin S. <sch...@pr...>]

Many thanx to Gerhard for getting me a workaround for 2.2 OpenSSL so now I can use PyPgSQL!

To wit: 

	I am having trouble getting mixed case entities working. Postgres doesn't make this real 
easy but the support is there and necessary for a project I am involved in that exports tables from 
Access into Postgres using IDENTICAL names so that, once simple ODBC connections are made 
to the back end, the existing Access front-end operates without modification. I have this part 
working but now want to talk to the backend database via a python app (which will eventually 
replace Access altogether) using PyPgSQL. Unfortunately this means I have to be able to refer to 
table and field names using their double-quoted mixed-case names but the PyPgSQL code doesn't 
seem to get along with it. Attached is a bit of sample code demonstrating the problem. Am I doing 
something wrong or is this support not yet available?

	many thanx,

		Ben Scherrey

------------------------------
from pyPgSQL import PgSQL

if __name__ == '__main__':
    src = PgSQL.connect( user="xxx", password="xxx", host="xxx", database="xxx" );
    cur = src.cursor()

    cstmt = ""
    sstmt = ""
    istmt = ""

    # Change this to demonstrate problem with mixed case...
    mixed = 0

    if not mixed:    
        cstmt = r"""create table test ( fname varchar(20), lname varchar(20) )"""
        istmt = r"""insert into test values ( 'Benjamin', 'Scherrey' )"""
        sstmt = r"""select fname, lname from test"""
        
    else:
        cstmt = r"""create table "Test" ( "FName" varchar(20), "LName" varchar(20) )"""
        istmt = r"""insert into "Test" values ( 'Benjamin', 'Scherrey' )"""
        sstmt = r"""select "FName", "LName" from "Test" """
        
    
    print cstmt
    cur.execute( cstmt )
        
    print istmt
    cur.execute( istmt )
    
    print sstmt
    cur.execute( sstmt )

    res = cur.fetchone()
    print res["fname"]
    print res["lname"]
    
    cur.close()
    src.close() 

----------------------

Re: [Pypgsql-users] Support for Python 2.3 beta under windows...

[<gh...@gh...>]

Benjamin Scherrey wrote:
> Thanx - I'm trying to do just that but I'm having a bad time trying to get the eGenix mx extensions to 
> build. No luck so far so I can't build pypgsql either... :-( I'm using the urllib2 client HTTPS 
> connection for a secure credit card processor that talks to Authorize.net. HTTPS is only available in 
> the 2.3 alpha version of python. So far everything else supports it but my pyphsql stuff. 
> Unfortunately that's kinda an important point...

The answer for your problem is still the same:

http://pypgsql.sourceforge.net/misc/python-ssl.html

A SSL-enabled _socket.pyd replacement for Python 2.2.x. Makes 
HTTPS/smtplib.starttls() etc. work.

It's just a coincidence that I put it on the pyPgSQL page during the 
time where I had no webspace of my own.

So you won't have to mess with Python 2.3, yet.

-- Gerhard

Re: [Pypgsql-users] Support for Python 2.3 beta under windows...

[Benjamin S. <sch...@pr...>]

Thanx - I'm trying to do just that but I'm having a bad time trying to get the eGenix mx extensions to 
build. No luck so far so I can't build pypgsql either... :-( I'm using the urllib2 client HTTPS 
connection for a secure credit card processor that talks to Authorize.net. HTTPS is only available in 
the 2.3 alpha version of python. So far everything else supports it but my pyphsql stuff. 
Unfortunately that's kinda an important point...

	best regards,

		Ben Scherrey

3/29/2003 11:29:05 PM, Gerhard Häring <gh...@gh...> wrote:

>* Benjamin Scherrey <sch...@pr...> [2003-03-29 22:07 -0500]:
>> Is there (or will there soon be) a build available for Python 2.3 win32?
>
>As soon as somebody builds one. You could, too. Only free tools are
>required to do so. There's even a README.win32 in the pyPgSQL source
>distribution.
>
>> I'd really like to use pypgsql for my app but, unfortunately, I
>> required the "https" connectivity that isn't available in the 2.2
>> release.
>
>I've once made a replacement SSL-enabled _socket.pyd that's currently
>available at:
>
>http://pypgsql.sourceforge.net/misc/python-ssl.html
>
>I'll most likely move it to my new homepage soon (see sig).