Undeliverable Message - Mailing list pgsql-interfaces

To:            ISMTP@SFRA0046@Servers[<pgsql-interfaces-digest@hub.org>]
Cc:            
Subject:       pgsql-interfaces-digest V1 #411

Message not delivered to recipients below.  Press F1 for help with VNM
error codes.               
VNM3043:  DE_VOLDER Fabrice@ATR_EXPL_LYON1@SFR_DO_CNTR_EST



VNM3043 -- MAILBOX IS FULL
  The message cannot be delivered because the  recipient's mailbox contains the maximum number of   messages, as set by
thesystem administrator.  The  recipient must delete some messages before any  other messages can be delivered.   The
maximummessage limit for a user's mailbox is   10,000.  The default message limit is 1000 messages.    Administrators
canset message limits using the   Mailbox  Settings function available in the   Manage User menu  (MUSER). 
 
  When a user's mailbox reaches the limit, the   user must delete some of the messages before   the mailbox can accept
anymore incoming messages.
 

----------------------  Original Message Follows  ----------------------


pgsql-interfaces-digest     Thursday, July 8 1999     Volume 01 : Number 411



Index:

[INTERFACES] JDBC escape problem
RE: [INTERFACES] JDBC escape problem
Libpq and Borland C++ Builder 4
RE: [INTERFACES] Libpq and Borland C++ Builder 4
RE: [INTERFACES] Libpq and Borland C++ Builder 4
java and postgresql 6.5
java in postgresql 65
libpq AND C++ Builder
No suitable driver
transactions in libpq++ require new connection? 
Postgresql + lo
Re: [INTERFACES] libpq AND C++ Builder
NEW WEB INTERFACE for PostgreSQL
Re: [INTERFACES] Postgresql + lo 
Re: [INTERFACES] transactions in libpq++ require new connection? 

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

Date: Thu, 08 Jul 1999 00:56:51 -0700
From: Rolland Crunk <rc@aenet.net>
Subject: [INTERFACES] JDBC escape problem

I'm encountering a problem with the implementation of escapes using
the 6.5 JDBC driver.  If I attempt to insert a timestamp value using
the following syntax, I get an error from the postgreSQL parser complaining
about the '{' character:
 stmt.executeUpdate("insert into tstest values ( { ts '1999-07-07 00:00:00' } )");

However, the following statement works:
 stmt.executeUpdate("insert into tstest values ( '{ ts 1999-07-07 00:00:00 }' )");

Unfortunately, the former is the correct syntax where the second isn't.

>From what I could determine tracing the code, there is no escape processing
performed in the PostgreSQL jdbc driver, and the error is originating from the
database backend.

I thought it unusual that I didn't see reference to this problem in the mail
archives (though I admit I only went back a few months).  Is this a known
problem?  

What are the consequences of fixing it in the back-end?  Will it break other 
drivers that depend on this syntax?  

Any advise would be appreciated.

Thanks in advance,

rc

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

Date: Thu, 8 Jul 1999 09:34:53 +0100 
From: Peter Mount <petermount@it.maidstone.gov.uk>
Subject: RE: [INTERFACES] JDBC escape problem

This is probably caused by the fact that currently we don't parse
anything within the JDBC driver. I'll put it on my todo list for 6.6.

- -----Original Message-----
From: Rolland Crunk [mailto:rc@aenet.net]
Sent: 08 July 1999 08:57
To: pgsql-interfaces@hub.org
Subject: [INTERFACES] JDBC escape problem




I'm encountering a problem with the implementation of escapes using
the 6.5 JDBC driver.  If I attempt to insert a timestamp value using
the following syntax, I get an error from the postgreSQL parser
complaining
about the '{' character:
 stmt.executeUpdate("insert into tstest values ( { ts '1999-07-07
00:00:00' } )");

However, the following statement works:
 stmt.executeUpdate("insert into tstest values ( '{ ts 1999-07-07
00:00:00 }' )");

Unfortunately, the former is the correct syntax where the second isn't.

>From what I could determine tracing the code, there is no escape
processing
performed in the PostgreSQL jdbc driver, and the error is originating
from the
database backend.

I thought it unusual that I didn't see reference to this problem in the
mail
archives (though I admit I only went back a few months).  Is this a
known
problem?  

What are the consequences of fixing it in the back-end?  Will it break
other 
drivers that depend on this syntax?  

Any advise would be appreciated.

Thanks in advance,

rc

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

Date: Thu, 08 Jul 1999 11:22:49 +0200
From: Jean-Christophe FABRE <fabrejc@ensam.inra.fr>
Subject: Libpq and Borland C++ Builder 4

Hi!

When I try to use the libpq.lib (from the win32 psql.exe interface tool)
library with BC++ Builder, I get a message : LIBPQ.LIB contains invalid
OMF record, type 0x21 (possibly COFF).

First of all, what are OMF and COFF ?

I've found a tool (in C++Builder bin directory) to convert COFF2OMF, but
it didn't work.

Does anybody has a re-compiled libpq.lib which works fine with
C++Builder 4 ?

Please help!

Thanks

JC.Fabre

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

Date: Thu, 8 Jul 1999 11:31:47 +0200 
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
Subject: RE: [INTERFACES] Libpq and Borland C++ Builder 4

Welcome to the world of Win32.  There are several different object formats
when you are compiling under Win32.  It would appear that this error is
caused by your linker expecting one type when it actually gets another.
There may be an option somewhere to adjust your linker settings to cope with
a different object format.
This is a problem that is generally not experienced under UNIX, because
there is only one object format (that I'm aware of).

I'm not sure why you rconversion tool is not working, though, I suggest
getting hold of Inprise.


MikeA


>> When I try to use the libpq.lib (from the win32 psql.exe 
>> interface tool)
>> library with BC++ Builder, I get a message : LIBPQ.LIB 
>> contains invalid
>> OMF record, type 0x21 (possibly COFF).
>> 
>> First of all, what are OMF and COFF ?
>> 
>> I've found a tool (in C++Builder bin directory) to convert 
>> COFF2OMF, but
>> it didn't work.
>> 
>> Does anybody has a re-compiled libpq.lib which works fine with
>> C++Builder 4 ?
>> 
>> Please help!
>> 
>> Thanks
>> 
>> JC.Fabre
>> 
>> 

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

Date: Thu, 8 Jul 1999 13:13:57 +0200 
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
Subject: RE: [INTERFACES] Libpq and Borland C++ Builder 4

Perhaps you should just get hold of the Win32 source, and compile the entire
library again.  This would probably be the easiest solution.  I think that
the format that it is in is what VC++ uses.  I seem to remember trying it
out a while back.  However, if you get the source code, it shouldn't be a
problem to compile it.
>> 
>> Welcome to the world of Win32.  There are several different 
>> object formats
>> when you are compiling under Win32.  It would appear that 
>> this error is
>> caused by your linker expecting one type when it actually 
>> gets another.
>> There may be an option somewhere to adjust your linker 
>> settings to cope with
>> a different object format.
>> This is a problem that is generally not experienced under 
>> UNIX, because
>> there is only one object format (that I'm aware of).
>> 
>> I'm not sure why you rconversion tool is not working, 
>> though, I suggest
>> getting hold of Inprise.
>> 
>> 
>> MikeA
>> 
>> 
>> >> When I try to use the libpq.lib (from the win32 psql.exe 
>> >> interface tool)
>> >> library with BC++ Builder, I get a message : LIBPQ.LIB 
>> >> contains invalid
>> >> OMF record, type 0x21 (possibly COFF).
>> >> 
>> >> First of all, what are OMF and COFF ?
>> >> 
>> >> I've found a tool (in C++Builder bin directory) to convert 
>> >> COFF2OMF, but
>> >> it didn't work.
>> >> 
>> >> Does anybody has a re-compiled libpq.lib which works fine with
>> >> C++Builder 4 ?
>> >> 
>> >> Please help!
>> >> 
>> >> Thanks
>> >> 
>> >> JC.Fabre
>> >> 
>> >> 
>> 

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

Date: Thu, 8 Jul 1999 15:32:20 +0200 (CEST)
From: <yves@vlaanderen.net>
Subject: java and postgresql 6.5

I've been upgrading postgresql 6.4.2 to 6.5. It seems like the jdbc driver
included with postgres 65 doesn't work correctly:
java.lang.IllegalArgumentException: Argument # > Arg length

or am i doing something wrong ?

- -Yves

On Fri, 14 May 1999, Alf Lewerken wrote:

> Hi all
> 
> I have the following problem:
> I'm using libpq++ to acces a Postgres-Database.
> 
> The table was created in psql using:
> create table test values (nr int4, some_value float4[]);
> 
> in my C++-program a piece of code is:
> 
> main()
> {
>   char *nr_string, *some_other_string;
> 
>   PgDatabase test(pgenv, "test");
>   test.Exec("begin");
>   test.Exec("declare c cursor for select * from test");
>   
>   for(int ist.Tuples();i++)
>   {
>      nr_string > 
>      some_other_string >      // PQgetvalue: ERROR! field number -1 is out of range
>    
>      // so how do I obtain values in some_value[1], some_value[2] .... ?
>   }
> }
> 
> any help would be appreciated.
> 
> 
> bye
> 
> 
> Alf Lewerken
> 

First, they ignore you.
Then they laugh at you.
Then they fight you.
Then you win.             -- M. Ghandi

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

Date: Thu, 8 Jul 1999 15:40:16 +0200 (CEST)
From: <yves@vlaanderen.net>
Subject: java in postgresql 65

I've been upgrading postgresql 6.4.2 to 6.5. It seems like the jdbc driver
included with postgres 65 doesn't work correctly: java.lang.IllegalArgumentException: Argument # > Arg length
or am i doing something wrong ?-Yves

First, they ignore you.
Then they laugh at you.
Then they fight you.
Then you win.             -- M. Ghandi

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

Date: Thu, 08 Jul 1999 16:00:43 +0200
From: Jean-Christophe FABRE <fabrejc@ensam.inra.fr>
Subject: libpq AND C++ Builder

Does anybody have a libpq.lib (or libpq++.lib) win32 version which works
fine with Borland C++ builder 4, or know where I can find it.

I tried to re-compile it with C++B4, but no luck.

The version which comes with the psql.exe distribution doesn't work
either.

Thanks

JC

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

Date: Thu, 08 Jul 1999 11:38:24 -0400
From: "C.J. Pena" <cjp@professionalmedia.com>
Subject: No suitable driver

Hello,
I am using the Postgre v6.5-JDK11 driver (also tried the Postgre v6.4
driver) and
I receive "No suitable driver" error when I try to establish a
connection.
The registration -- Class.forname('postgresql.Driver') -- executes Ok.
This error leads me to believe the problem is in driver setup; if I
received something like
"connection refused" I would look first at security, say in pg_hba.conf,
right?
Thank you.

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

Date: Thu, 8 Jul 1999 15:55:59 -0400 (EDT)
From: George Young <gry@ll.mit.edu>
Subject: transactions in libpq++ require new connection? 

I am using libpq++ with gcc egcs-2.91.66 (egcs-1.1.2 release) on RH linux 5.1
with Postgres 6.5.  I need to use transactions to maintain consistency
when an application's logical operation actually updates multiple tables.

Currently, the PgTransaction class only has a public constructor which
opens a new connection to the DB, and closes it on commit.  For an application
making many short transactions, in an environment with many active clients,
this seems to be very wasteful of network and cpu resources.  Is there some
reason a PgTransaction could not be constructed from an existing PgDatabase
(or PgConnection)?  Maybe trans should be a lightweight class to avoid
problems with inheriting from PgDatabase and thus having to deal with 
copy/reference-count etc. problems?

I know I can roll my own by just Exec("begin"), etc, but having the
transaction *committed* (not conn closed) in the destructor would be very
handy.


Also, there's no rollback member...


On yet another note, it would be much neater if the c++ interface would use
'string' type for text args and returns.  I'm tired of writing foo.c_str()
everywhere...


Thanks,George

[I'm not too experienced with c++, so I *welcome* any comments/suggestions]


George Young,  Rm. L-204        gry@ll.mit.edu
MIT Lincoln Laboratory
244 Wood St.
Lexington, Massachusetts  02420-9108    (781) 981-2756

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

Date: Fri, 9 Jul 1999 00:19:51 +0200
From: Florian Baumert <baumert@plt.de>
Subject: Postgresql + lo

Hi there,

I have a major problem with postgresql 6.5. In my database, I've
created the lo-type, as explained in the FAQ. I have a table which
uses this type. If i want to acces it with (eg) perl     use Pg; $conn The xinv33025 exists and the oid 33025 was
createdby a call to lo_create.
 

What happens is that it writes a -1 to the screen and a database-error "ERROR: lo_lseek: invalid large obj descriptor
(0)"
The same happens, if I use php3 (compiled against postgresql) and the
ODBC-driver for windoes (06.40.0006). If i compile and start
examples/test/lotest.c (hope, it's the right name) in the
posrgresql-src directory, it works!!!

If I comment out the call to lo_lseek in lo_open, it works further,
but then I get problems in lo_close (same error as above, only in
lo_close).

What happens here?

Thanx in advance
     Florian

                     \\|||//                     |     |                     (.) (.)
! Florian Baumert                                       !
? Birkenweg 2                                           ?
! D-61267 Neu-Anspach                                   ?
! Tel.:06081-9 63 63 7                                  !
? ! baumert@plt.de                             www.plt.de !

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

Date: Thu, 8 Jul 1999 18:25:13 -0400 (EDT)
From: "Geoffrey C. Speicher" <geoff@sirius.trassociates.com>
Subject: Re: [INTERFACES] libpq AND C++ Builder

> Does anybody have a libpq.lib (or libpq++.lib) win32 version which works
> fine with Borland C++ builder 4, or know where I can find it.

Any reason you don't want to use ODBC with BCB4?  Grab the driver from
http://www.insightdist.com/psqlodbc/ and set up a System DSN; all the BCB
data-aware components work just swell with it ... don't forget to check
"recognize unique indexes" in the advanced driver settings, or it will
probably crash on you like it did for me.

Or did you want to implement native versions of the components for
PostgreSQL?  :)

Geoff

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

Date: Thu, 8 Jul 1999 14:39:49 -0400 (EDT)
From: seb@Panther4095.eiu.edu
Subject: NEW WEB INTERFACE for PostgreSQL

Hi all,

sorry if get this mail 2 or 3 times!

I am working on a CGI (perl) to access ANY postgres DB 
from the web: "PGase"

Here are the main features:

_ Login page to enter the CGI (default guest OK!).

_ Select/Insert/Update/Delete with just the mouse.    (foreign keys are links to primary key table!)

_ Import/Export data from/to flat .txt files   
_ UPLOAD SQL scripts from IMPORT to create database structure  directly from the CGI, or put data back from a pg_dump.

_ Administration also through a CREATE (SQL commands) page.

_ little HELP... :)

_ build queries dynamically (point & click: basic but OK   even when referential integrity between 2 tables).

_ run perfect with LYNX!!!

_ record queries 
_ Pie CHARTs on a selected field in a table.


Still to do:

_ FIND functions to get any records having "$string"   in one of its fields...  or between dates...

_ IP control access from the CGI.

_ few bugs to correct

_ move to mod_perl

_ lots of other ideas, like BLOBS, personalized forms...

Do you like the CGI?
What would you change?
What would you like to see?
Feel free to give me any advices!
'Say that's for the PostgreSQL community!  ;)

Thanks for your help,
Have fun,                               Sebastien.

Oups, maybe you need this:
http://panther4095.eiu.edu/PGase

The code:
http://math.eiu.edu/seb/cgi-bin/pg                                               
._...... _...._...._...._...._..._ ......_
|.|.....(_)..|.\..|.|..|.|..|.|..\.\..././ Sebastien Flacher
|.|.....|.|..|..\.|.|..|.|..|.|...\.\././
|.|.....|.|..|...\|.|..|.|..|.|..../._.\   phone: 217.345.8874
|.|___..|.|..|.|\...|..|.|__|.|..././.\.\  email: seb@math.eiu.edu
|_____).|_| .|_|.\__|..|______|../_/...\_\ web site: math.eiu.edu/seb

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

Date: Thu, 08 Jul 1999 21:16:14 -0400
From: Tom Lane <tgl@sss.pgh.pa.us> 
Subject: Re: [INTERFACES] Postgresql + lo 

Florian Baumert <baumert@plt.de> writes:
> What happens is that it writes a -1 to the screen and a database-error "ERROR: lo_lseek: invalid large obj descriptor
(0)"

This needs to go into the FAQ, I think, 'cause you're about the third
person to ask the same question in the past couple weeks.

You need to wrap a transaction ("begin" ... "commit") around any use
of a large object handle, ie any lo_open ... lo_close sequence.

This requirement has always been in the LO docs, but Postgres 6.5 is the
first release that enforces the rule (by closing all open LO handles at
end of statement, if not within a transaction).  In prior versions,
you could sometimes get away with not using a transaction, but it
was NOT reliable.
        regards, tom lane

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

Date: Thu, 08 Jul 1999 21:20:58 -0400
From: Tom Lane <tgl@sss.pgh.pa.us> 
Subject: Re: [INTERFACES] transactions in libpq++ require new connection? 

George Young <gry@ll.mit.edu> writes:
> Currently, the PgTransaction class only has a public constructor which
> opens a new connection to the DB, and closes it on commit.

Ugh.  I agree that's pretty awful.

> I know I can roll my own by just Exec("begin"), etc, but having the
> transaction *committed* (not conn closed) in the destructor would be very
> handy.
> Also, there's no rollback member...

Actually, I think the cleanest design would be to have a commit() member
function.  If the object is destroyed without having committed, the
default behavior ought to be to abort (rollback), not commit.  The
reason I think this is that if you imagine a PgTransaction object that
is local to a function, and the function is exited by an exception,
you probably want abort to happen rather than commit.

There might be some cases where you'd rather it worked the other way
around --- if so, we could have a constructor option to set the default
behavior at destruct time.  But I think defaulting to abort would be the
safest behavior for a program that uses exceptions.
        regards, tom lane

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

End of pgsql-interfaces-digest V1 #411
**************************************