Celeste Suliin Burris | 1 Dec 2004 01:50
Picon
Picon

Can't compile psqlodbc on Solaris 8

When I try to compile psqlodbc on Solaris 8, it fails. I'm not sure 
what I'm doing wrong.
  gcc version 3.4.0
  GNU libtool 1.4.2
  GNU Make 3.80
  solaris 8 linker on Solaris 8 sparc.

configured with the options - --enable-shared --with-iodbc 
--with-odbcinst=/usr/local/etc

errors look like this -

source='environ.c' object='environ.lo' libtool=yes \
depfile='.deps/environ.Plo' tmpdepfile='.deps/environ.TPlo' \
depmode=gcc3 /bin/sh ./depcomp \
/bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.     -g 
-O2 -c -o environ.lo `test -f 'environ.c' || echo './'`environ.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c environ.c -MT environ.lo -MD 
-MP -MF .deps/environ.TPlo  -fPIC -DPIC -o environ.lo
environ.c:233: error: conflicting types for 'PGAPI_StmtError'
pgapifunc.h:78: error: previous declaration of 'PGAPI_StmtError' was 
here
environ.c:233: error: conflicting types for 'PGAPI_StmtError'
pgapifunc.h:78: error: previous declaration of 'PGAPI_StmtError' was 
here
environ.c:465: error: conflicting types for 'PGAPI_ConnectError'
pgapifunc.h:74: error: previous declaration of 'PGAPI_ConnectError' was 
here
environ.c:465: error: conflicting types for 'PGAPI_ConnectError'
pgapifunc.h:74: error: previous declaration of 'PGAPI_ConnectError' was 
(Continue reading)

Dave Page | 1 Dec 2004 10:55
Picon

Re: psqlodbc installer


> -----Original Message-----
> From: eugen stefanescu [mailto:eugen_ste <at> hotmail.com] 
> Sent: 01 December 2004 09:13
> To: Dave Page
> Subject: Re: [ODBC] psqlodbc installer
> 
> I've "adapted "the psqlodbc driver to works (basically) with 
> other database .

Err, OK. 

> Now I need the simplest windows installer! I 
> never made a windows installer.
> There is not some free tool to do this? I have VC++6.

Look at http://wix.sf.net. There are other free tools availabale, but I
have no experience of them.

Regards, Dave

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to majordomo <at> postgresql.org so that your
      message can get through to the mailing list cleanly

markw | 1 Dec 2004 14:50

New ODBC driver

What would be the best way to go about re-writing the ODBC driver to use
libpq? (I haven't looked at the code in years, the last time I looked at
it was to find a memory leak.)

Is it possible to do it in stages?

Is the transport sufficiently separated to do a quick change to use libpq
as the transport, and then gradually use more and more?

My only concern would be that a re-write would re-break a lot of
functionality.

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo <at> postgresql.org)

Dave Page | 1 Dec 2004 14:48
Picon

Re: New ODBC driver


> -----Original Message-----
> From: pgsql-odbc-owner <at> postgresql.org 
> [mailto:pgsql-odbc-owner <at> postgresql.org] On Behalf Of 
> markw <at> mohawksoft.com
> Sent: 01 December 2004 13:50
> To: pgsql-odbc <at> postgresql.org
> Subject: [ODBC] New ODBC driver
> 
> What would be the best way to go about re-writing the ODBC 
> driver to use libpq? (I haven't looked at the code in years, 
> the last time I looked at it was to find a memory leak.)
> 
> Is it possible to do it in stages?
> 
> Is the transport sufficiently separated to do a quick change 
> to use libpq as the transport, and then gradually use more and more?
> 
> My only concern would be that a re-write would re-break a lot 
> of functionality.

I haven't looked at it in depth, but I think you will essentially just
need to rewrite connection.c as a libpq wrapper.

I don't think it would be realistic to mix the two approaches though -
if only because they couldn't share a single database connection.

Regards, Dave.

---------------------------(end of broadcast)---------------------------
(Continue reading)

Robert Treat | 1 Dec 2004 15:20
Picon

Re: ODBC driver for Windows & future...

On Tuesday 30 November 2004 05:16, Simeó Reig wrote:
> >Hi,
> >
> >I think I'm not the only one to get worried about the future of the
> >PGSQL ODBC driver. Since Iroshi has left last year, I have seen fixes
> >now and then, but nobody seems to understand anymore how the driver
> >really works...
> >
> we have been using the driver since three years ago, we had made an
> application
> with 40 concurrent ODBC users, 144 tables and milions of rows, postgresql
> is fantastic, with a great performance (dell 2650 dual processor raid 10)
> and the most important : zero problems in three years.
>
> Now, we have to make other application but we will not use postgresql
> because
> we don't trust ODBC project, seems nobody understands nothing !! 

So for three years you have taken from the work of hundreds of others who have 
provided you with a free database and a working driver to use along with it, 
but now when there are signs of trouble, you're just going to pack up and 
leave?  Why not dedicate just one of your programmers to working on the ODBC 
driver full time?  This way you can assure that all of your issues with the 
driver are still addressed, you'll save the costs of switching to another 
system, and still get an extremely robust database for the cost of one 
programmer? Seems like a good investment to me. 

--

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
(Continue reading)

Dave Page | 1 Dec 2004 15:53
Picon

Re: New ODBC driver


> -----Original Message-----
> From: markw <at> mohawksoft.com [mailto:markw <at> mohawksoft.com] 
> Sent: 01 December 2004 15:02
> To: Dave Page
> Cc: pgsql-odbc <at> postgresql.org
> Subject: Re: [ODBC] New ODBC driver
> 
> > I don't think it would be realistic to mix the two 
> approaches though - 
> > if only because they couldn't share a single database connection.
> 
> Why is this an issue? Why not create multiple connections?

Efficiency for a start - but what would you use each for? Any
application developer is going to expect everything to use the same
connection - how do you direct a 'SET' statement? What about transaction
isolation?

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Robert Treat | 1 Dec 2004 15:49
Picon

Re: ODBC driver for Windows & future...

On Tue, 2004-11-30 at 04:36, Philippe Lang wrote:
> What most surprises me, is that there is not viable commercial
> alternative to the open-source ODBC driver. All the commercial drivers I
> have tested do not work at all... 

Have you tested Command Prompts commercial ODBC driver
(http://www.commandprompt.com/entry.lxp?lxpe=296) ? It has SSL support
and is fully compatible with PostgreSQL. In fairness I haven't used it
but Command Prompt has a pretty good relationship with the PostgreSQL
community; I'm sure they'd be interested in any feedback you wanted to
give them.

Robert Treat 
--

-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

markw | 1 Dec 2004 16:01

Re: New ODBC driver

>
>
>> -----Original Message-----
>> From: pgsql-odbc-owner <at> postgresql.org
>> [mailto:pgsql-odbc-owner <at> postgresql.org] On Behalf Of
>> markw <at> mohawksoft.com
>> Sent: 01 December 2004 13:50
>> To: pgsql-odbc <at> postgresql.org
>> Subject: [ODBC] New ODBC driver
>>
>> What would be the best way to go about re-writing the ODBC
>> driver to use libpq? (I haven't looked at the code in years,
>> the last time I looked at it was to find a memory leak.)
>>
>> Is it possible to do it in stages?
>>
>> Is the transport sufficiently separated to do a quick change
>> to use libpq as the transport, and then gradually use more and more?
>>
>> My only concern would be that a re-write would re-break a lot
>> of functionality.
>
> I haven't looked at it in depth, but I think you will essentially just
> need to rewrite connection.c as a libpq wrapper.
>
> I don't think it would be realistic to mix the two approaches though -
> if only because they couldn't share a single database connection.

Why is this an issue? Why not create multiple connections?

(Continue reading)

markw | 1 Dec 2004 17:20

Re: New ODBC driver

>
>
>> -----Original Message-----
>> From: markw <at> mohawksoft.com [mailto:markw <at> mohawksoft.com]
>> Sent: 01 December 2004 15:02
>> To: Dave Page
>> Cc: pgsql-odbc <at> postgresql.org
>> Subject: Re: [ODBC] New ODBC driver
>>
>> > I don't think it would be realistic to mix the two
>> approaches though -
>> > if only because they couldn't share a single database connection.
>>
>> Why is this an issue? Why not create multiple connections?
>
> Efficiency for a start - but what would you use each for? Any
> application developer is going to expect everything to use the same
> connection - how do you direct a 'SET' statement? What about transaction
> isolation?
>
> Regards, Dave.

OK, I'm going to take a look at it.

I have a stupid question, where is the location of the ODBC source? Is it
part of PostgreSQL?

>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
(Continue reading)

Simeó Reig | 1 Dec 2004 17:28
Favicon

Re: ODBC driver for Windows & future...

----- Original Message ----- 
>From: "Robert Treat" <xzilla <at> XXXXXXXXXXXX>
>
>So for three years you have taken from the work of hundreds of others who
>have
>provided you with a free database and a working driver to use along with
it,
>but now when there are signs of trouble, you're just going to pack up and
>leave?  Why not dedicate just one of your programmers to working on the
>ODBC
>driver full time?  This way you can assure that all of your issues with the
>driver are still addressed, you'll save the costs of switching to another
>system, and still get an extremely robust database for the cost of one
>programmer? Seems like a good investment to me.

Yes, you are right. But we are not good c programmers, but we are going to
offer
our help to improve npgsql because it's written in c sharp.

The problem is not this, nobody can't help in every project. The problem is
that
odbc project is frozen since one year ago, well, solutions? I believe that
one
solutions could be rewrite all or make, if is it possible, a bridge between
odbc
project an other project.

Best regards

---------------------------(end of broadcast)---------------------------
(Continue reading)


Gmane