Ada & Postgresql

Ada & Postgresql

[Alex R. Mosteo]

Hi,

anyone doing the above? I've found three bindings:

* Apq
* Pgada
* Gnade

I suppose I could test the three, but has anyone already done that? I 
just need to do fairly simple insertions.

Thanks in advance,

A. Mosteo.

Re: Ada & Postgresql

[Adrian Knoth]

Alex R. Mosteo <devnull@mailinator.com> wrote:

> Hi,

Hi!

> * Pgada

Is this the pg2-stuff from Mario Amado Alve? If so, I use this[0] ;)


[0] http://adi.thur.de/?show=adabill

-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Acht Uhr? Morgens? Wach? Duschen? Das war kein Admin. (Jonas Luster in dasr)

Re: Ada & Postgresql

[Marius Amado Alves]

>>* Pgada
> Is this the pg2-stuff from Mario Amado Alve? If so, I use this[0] ;)
> [0] http://adi.thur.de/?show=adabill

Pgada /= Pg2. Nice to know Pg2 is beeing used. Let me take the chance 
make a long overdue update on this. On 2001 I've replaced Pg2 with 
Pgsql, for use in the European project SolEuNet, which ended 2003. I now 
make Pgsql available, at http://www.liacc.up.pt/~maa/files.

There's no need to go rushing upgrading your existing Pg2 application to 
Pgsql. But if you're starting a new application, I recommend Pgsql.

Pg2 was in my Adlib site which went down around that time. I'll try to 
set up a new shop soon with all the updated stuff as well as an 
historical copy of Adlib.

Re: Ada & Postgresql

[Pascal Obry]

"Alex R. Mosteo" <devnull@mailinator.com> writes:

> anyone doing the above? I've found three bindings:
> 
> * Apq
> * Pgada
> * Gnade

I've done many projects with GNADE/ODBC (both on GNU/Linux and Windows). It
works just fine.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Ada & Postgresql

[Alex R. Mosteo]

Pascal Obry wrote:
> "Alex R. Mosteo" <devnull@mailinator.com> writes:
> 
> 
>>anyone doing the above? I've found three bindings:
>>
>>* Apq
>>* Pgada
>>* Gnade
> 
> 
> I've done many projects with GNADE/ODBC (both on GNU/Linux and Windows). It
> works just fine.

I find the thin ODBC binding a bit frustrating (being thin). Are there 
plans in Gnade to build a simpler thick interface over it? (Maybe ADBC 
was in this line, but someone said it was discontinued).

However, the postgresql package is very simple.

Re: Ada & Postgresql

[Alex R. Mosteo]

Alex R. Mosteo wrote:
> Pascal Obry wrote:

>> I've done many projects with GNADE/ODBC (both on GNU/Linux and 
>> Windows). It
>> works just fine.
> 
> 
> I find the thin ODBC binding a bit frustrating (being thin). Are there 
> plans in Gnade to build a simpler thick interface over it? (Maybe ADBC 
> was in this line, but someone said it was discontinued).
> 
> However, the postgresql package is very simple.

Customary inspection & testing of the Gnu.Db.Postgresql shows a memory 
leak in the Database type. Some internal protected type isn't being freed.

I understand that normally database connections are declared once and 
reused, but there may be cases where this is not desired. Furthermore, 
if you don't want to keep the connection alive, the package doesn't 
provide close/reconnect procedures, so you'd be forced to use local 
scopes and then you'd run inexorably in this leak.

I CC to the maintainer.

Re: Ada & Postgresql

[Marius Amado Alves]

> Customary inspection & testing of the Gnu.Db.Postgresql shows a memory 
> leak in the Database type. Some internal protected type isn't being freed.

Note package Pgsql includes a procedure Forget for this effect.

    http://www.liacc.up.pt/~maa/files/Pgsql.zip

When Ada 2005 comes I think I'll make the connection type controlled to 
automatically call Forget on finalization. I didn't do that yet because 
of the unwarranted constraints Ada 95 puts on controlled types.

Re: Ada & Postgresql

[Alex R. Mosteo]

Marius Amado Alves wrote:
>> Customary inspection & testing of the Gnu.Db.Postgresql shows a memory 
>> leak in the Database type. Some internal protected type isn't being 
>> freed.
> 
> 
> Note package Pgsql includes a procedure Forget for this effect.

Ummm, I see no leak in the Gnade management of queries. I think they are 
transparently forgotten (on finalization). It is necessary in Pgsql to 
explicitly forget any returned result?

> 
>    http://www.liacc.up.pt/~maa/files/Pgsql.zip
> 
> When Ada 2005 comes I think I'll make the connection type controlled to 
> automatically call Forget on finalization. I didn't do that yet because 
> of the unwarranted constraints Ada 95 puts on controlled types.

Could you please elaborate on these unwarranted constraints? I suppose 
this is related to my previous paragraph and the difference between 
Pgsql and Gnade.

Thanks,

A. Mosteo.

Re: Ada & Postgresql

[Marius Amado Alves]

> Ummm, I see no leak in the Gnade management of queries. I think they are 
> transparently forgotten (on finalization). It is necessary in Pgsql to 
> explicitly forget any returned result?

Yes. In the current, uncontrolled, version, yes.

> Could you please elaborate on these unwarranted constraints? I suppose 
> this is related to my previous paragraph and the difference between 
> Pgsql and Gnade.

Controlled types in Ada 95 sometimes get in your way e.g. must be 
declared at library level. This will disappear in Ada 2005. But it's no 
big deal really. The result type should be controlled. Just make a 
Pgsql_Controlled wrapper package or something. I'll take a look at old 
Pgsql applications to see how this was dealt with.

Re: Ada & Postgresql

[Alex R. Mosteo]

Marius Amado Alves wrote:

> Controlled types in Ada 95 sometimes get in your way e.g. must be 
> declared at library level. This will disappear in Ada 2005. But it's no 
> big deal really. The result type should be controlled. Just make a 
> Pgsql_Controlled wrapper package or something. I'll take a look at old 
> Pgsql applications to see how this was dealt with.

There's some misunderstanding here because the Pgsql.Result_Type is 
already defined at library level so it could be controlled right now.

?

Re: Ada & Postgresql

[Marius Amado Alves]

> There's some misunderstanding here because the Pgsql.Result_Type is 
> already defined at library level so it could be controlled right now.

You're probably right. I can't pinpoint now what annoying Ada 95 feature 
I was escaping back in 2001 when I wrote this package and its 
applications. Never mind. Just write Pgsql_Controlled.

Re: Ada & Postgresql

[Marius Amado Alves]

> ... I can't pinpoint now what annoying Ada 95 feature 
> I was escaping back in 2001 when I wrote this package and its 
> applications. Never mind. Just write Pgsql_Controlled.

Just noticed, Pgsql (spec) already withens Ada.Finalization--but does 
not use it! Clearly I must have planned to control the types, or maybe 
even tried it and backed off when Ada 95 got in the way :-)

Re: Ada & Postgresql

[Marius Amado Alves]

> ...I can't pinpoint now what annoying Ada 95 feature 
> I was escaping back in 2001 when I wrote this package and its 
> applications. Never mind. Just write Pgsql_Controlled.

OK, I just took the time to write this. While I'm at it, I'll control 
also Db_Type, to call Close on finalization. Oops, no, Ada 95 does not 
let me do that, it makes

    function Execute (Db: Db_Type; Command: String) return Result_Type;

illegal, because an "operation can be dispatching in only one type."

This is one of many examples of what I call "Ada getting in the way."

Re: Ada & Postgresql

[Martin Dowie]

Marius Amado Alves wrote:
>> ...I can't pinpoint now what annoying Ada 95 feature
>> I was escaping back in 2001 when I wrote this package and its
>> applications. Never mind. Just write Pgsql_Controlled.
>
> OK, I just took the time to write this. While I'm at it, I'll control
> also Db_Type, to call Close on finalization. Oops, no, Ada 95 does not
> let me do that, it makes
>
>     function Execute (Db: Db_Type; Command: String) return
> Result_Type;
>
> illegal, because an "operation can be dispatching in only one type."
>
> This is one of many examples of what I call "Ada getting in the way."

But isn't the solution to this to just wrap one of them in a 'plain' record,
e.g.

package Foo is
   type Command_Type is private;
   type Result_Type is private;
   -- whatever
   function Bar (CT : Command_Type) return Result_Type;
private
   type Command_Type is new Ada.Controlled...
   procedure Finalize (C : in out Command_Type);

   type Inner_Result_Type is new Ada.Controlled...
   procedure Finalize (IR : in out Inner_Result_Type);

   type Result_Type is record
      IR : Inner_Result_Type;
   end record;
end Foo;

Cheers

-- Martin

Re: Ada & Postgresql

[Marius Amado Alves]

> But isn't the solution to this to just wrap one of them in a 'plain' record...

Yes. But that's a solution to the language annoyance, not to the 
problem.  I mean, just look at all the fuss you have to go thru just to 
catch finalization.

Update Pgsql with controlled version anyway.

Re: Ada & Postgresql

[Dmitry A. Kazakov]

On Mon, 06 Sep 2004 13:43:56 +0100, Marius Amado Alves wrote:

>> ...I can't pinpoint now what annoying Ada 95 feature 
>> I was escaping back in 2001 when I wrote this package and its 
>> applications. Never mind. Just write Pgsql_Controlled.
> 
> OK, I just took the time to write this. While I'm at it, I'll control 
> also Db_Type, to call Close on finalization. Oops, no, Ada 95 does not 
> let me do that, it makes
> 
>     function Execute (Db: Db_Type; Command: String) return Result_Type;
> 
> illegal, because an "operation can be dispatching in only one type."

Well, Ada does not have multiple dispatch...

> This is one of many examples of what I call "Ada getting in the way."

But very probably it is not what you actually need. I suppose that the
Result_Type'Class hierarchy (if any) is independent to one of
Db_Type'Class. So the Execute could be contravariant in its result:

function Execute (Db: Db_Type; Command: String)
   return Result_Type'Class;

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Ada & Postgresql

[Marius Amado Alves]

> Well, Ada does not have multiple dispatch...

I know. The matter is, I don't want multiple dispatch, nor 'Class, nor 
tagged types. I just want to catch finalization. But no problem, we just 
write twice the code, to keep writing in Ada.

Re: Ada & Postgresql

[Dmitry A. Kazakov]

On Mon, 06 Sep 2004 15:33:24 +0100, Marius Amado Alves wrote:

>> Well, Ada does not have multiple dispatch...
> 
> I know. The matter is, I don't want multiple dispatch, nor 'Class, nor 
> tagged types. I just want to catch finalization. But no problem, we just 
> write twice the code, to keep writing in Ada.

It is unfortunate that Ada does not have user-definable destructors for all
types, rather than for the controlled only.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Ada & Postgresql

[Jean-Marc Bourguet]

Marius Amado Alves <amado.alves@netcabo.pt> writes:

> > ...I can't pinpoint now what annoying Ada 95 feature I was escaping back
> > in 2001 when I wrote this package and its applications. Never mind. Just
> > write Pgsql_Controlled.
> 
> OK, I just took the time to write this. While I'm at it, I'll control also
> Db_Type, to call Close on finalization. Oops, no, Ada 95 does not let me do
> that, it makes
> 
>     function Execute (Db: Db_Type; Command: String) return Result_Type;
> 
> illegal, because an "operation can be dispatching in only one type."

The fact that all (well I'm not sure, that's so long ago that I could
program in Ada, and it make me think about freezing rules that I've
never really mastered) subroutines defined in the same package as a
type having that type as argument or result are primitive operations
is sometimes annoying, but there is an easy work around: provide it in
a nested package and then use a renaming.

Yours,

-- 
Jean-Marc

Re: Ada & Postgresql

[Marius Amado Alves]

GNADE vs. Pgsql.

Pgsql is a simple Ada binding to Postgres.
GNADE is a very big [1] Ada library encompassing various database 
systems (Postgres, MySQL, etc.) and protocols (ODBC).
Pick the proper thing for you application. Use Pgsql when you simply 
want to bind to Postgres and don't need ODBC.

Now comparing oranges with oranges, i.e. considering the Postgres 
binding of GNADE, Gnu.Db.Postgres, vs. Pgsql.

As noted, Gnu.Db.Postgres has a leak in the connection area. But has 
controlled queries that automatically reclaim memory on finalization. 
Pgsql has no leaks per se, but in its current version the types are not 
controlled, so the user has to reclaim memory him self. Pick you poison.

However, I think the main difference is in the style of the Ada spec. 
Unfortunately I'm not able to look at Gnu.Db.Postgres right now [2], but 
from what I recall from my examination of the landscape some time ago, 
which has probably included Gnu.Db.Postgres, they are much longer and 
harder to use than Pgsql.

[1] The RPM has 6M, but I don't know what's in it. See note 2.

[2] The Sourceforge site seems to only provide RPM files. How do I read 
this in my Windows XP laptop? Also, when I click the version number on 
the site (hoping to browse the files), I get XML garbage.

Re: Ada & Postgresql

[Alex R. Mosteo]

Marius Amado Alves wrote:
> As noted, Gnu.Db.Postgres has a leak in the connection area. But has 
> controlled queries that automatically reclaim memory on finalization. 
> Pgsql has no leaks per se, but in its current version the types are not 
> controlled, so the user has to reclaim memory him self. Pick you poison.

The leak in Gnade is probably safe to ignore as long you know it exists. 
If you only use a connection during the app lifetime you're safe. 
Otherwise you have a 48 byte penalty for each one. It is very easy to 
patch, btw, so it is not really a deterrent.

> However, I think the main difference is in the style of the Ada spec. 
> Unfortunately I'm not able to look at Gnu.Db.Postgres right now [2], but 
> from what I recall from my examination of the landscape some time ago, 
> which has probably included Gnu.Db.Postgres, they are much longer and 
> harder to use than Pgsql.

This may have changed, since my inspection of Gnade shows an almost 
equal simplicity between it and Pgsql. One call to connect, one call 
with the textual SQL query, and a result type accessible by indexes.

The ODBC thin binding is another kind of beast, as already noted.

> [2] The Sourceforge site seems to only provide RPM files. How do I read 
> this in my Windows XP laptop? Also, when I click the version number on 
> the site (hoping to browse the files), I get XML garbage.

Check the source distribution, it has .tgz file and furthermore it 
includes the examples, which the linux binary (don't know about the 
windows one) one doesn't.

Or take this link

http://sourceforge.net/project/showfiles.php?group_id=23045&package_id=19410

to reach the binary installable for windows.

Re: Ada & Postgresql

[Marius Amado Alves]

> Check the source distribution, it has .tgz file and furthermore it 
> includes the examples, which the linux binary (don't know about the 
> windows one) one doesn't.

Not sure Windows can open a TGZ either, and in Sourceforge I only find 
RPMs, but thanks.

Re: Ada & Postgresql

[Björn Persson]

Marius Amado Alves wrote:

> Not sure Windows can open a TGZ either

Winzip can, and various other compression programs for Windows too.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Ada & Postgresql

[Marius Amado Alves]

>> Customary inspection & testing of the Gnu.Db.Postgresql shows a memory 
>> leak in the Database type...

> Note package Pgsql includes a procedure Forget for this effect...

Correction: it's procedure Close for connections; Forget is for results. 
Sorry.

Re: Ada & Postgresql

[Alex R. Mosteo]

Marius Amado Alves wrote:
>>> Customary inspection & testing of the Gnu.Db.Postgresql shows a 
>>> memory leak in the Database type...
> 
> 
>> Note package Pgsql includes a procedure Forget for this effect...
> 
> 
> Correction: it's procedure Close for connections; Forget is for results. 
> Sorry.

Noted ;)

Re: Ada & Postgresql

[Dmitry A. Kazakov]

On Mon, 06 Sep 2004 10:42:27 +0200, Alex R. Mosteo wrote:

> I find the thin ODBC binding a bit frustrating (being thin).

Yep. I had to wrap them into controlled objects when used them. Also ODBC
itself is a nightmare. It customary uses null pointers as valid values and
when GNADE has an anonymous access parameter for that, then, well, you have
a problem. Yet it works.

> Are there 
> plans in Gnade to build a simpler thick interface over it? (Maybe ADBC 
> was in this line, but someone said it was discontinued).

Pity if it is so. For many projects ADBC could be a decisive advantage (of
Ada). Our customers for instance never want to be bound to a concrete DBMS.
So the choice is between bad (ODBC) and worse (raw SQL).

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Ada & Postgresql

[Jerry van Dijk]

"Alex R. Mosteo" <devnull@mailinator.com> writes:

> in Gnade to build a simpler thick interface over it? (Maybe ADBC was in this
> line, but someone said it was discontinued).

I sincerely hope not, as I am using the spec.

-- 
--  Jerry van Dijk
--  Leiden, Holland

Re: Ada & Postgresql

[Alex R. Mosteo]

Jerry van Dijk wrote:
> "Alex R. Mosteo" <devnull@mailinator.com> writes:
> 
> 
>>in Gnade to build a simpler thick interface over it? (Maybe ADBC was in this
>>line, but someone said it was discontinued).
> 
> 
> I sincerely hope not, as I am using the spec.

I even seem to remember that was one of the developers who said that. 
But he said too that it was because lack of general interest, and we are 
seeing that's not the case ;)

So maybe it will rise from the ashes again, or maybe it was a thought 
but development never has really stopped. I liked a lot what I saw in 
ADBC when I checked it, long time ago.

A. Mosteo.

Re: Ada & Postgresql

[Wojtek Narczynski]

Hello,

We used APQ, with MySQL, but PostgreSQL was its primary database, and
found it to be very high quality, with outstanding documentation.

Regards,
Wojtek

Re: Ada & Postgresql

[Warren W. Gay VE3WWG]

Wojtek Narczynski wrote:

> Hello,
> 
> We used APQ, with MySQL, but PostgreSQL was its primary database, and
> found it to be very high quality, with outstanding documentation.
> 
> Regards,
> Wojtek

One of the primary reasons for me to write APQ was to make it as easy
as it can be to use a database from Ada, without discarding strong
typing and full support for NULL values. APQ includes a number of
generic routines to preserve that strong typing between the database
types and your application.

APQ also now supports MySQL, and in the future (maybe this fall), it
will support Sybase as well (Sybase now allows free developer use of
Linux and Windows versions of the server, with no expiry).

With a little extra effort, you can also write your application to be
database neutral.

Thanks for the kind words for the documentation. I went to a lot
of trouble to make the documentation complete and easy to use.
Each function (or object) includes a code snippet, showing its use.
Exceptions are documented.

My biggest concern however is always application deployment. I can
make just about anything work for myself. Making an open sourced
package easy for someone else to install and use is more difficult.
This is the main reason I stayed away from UNIXODBC. This is less
of an issue on Windows, but I never really felt that ODBC was the
way to go anyway. APQ only requires GNAT, and the database software
client libraries (libpq or the mysql libraries). This makes it
much easier to deploy than GNADE for example.

Finally, if you are using Windows and want a point and click install,
there is a Windows install package too. Just click and point and
then you are ready to compile your Ada SQL application. It comes
with an uninstaller if you choose to use it.

For a sample of how easy it is, here are two Ada source bodies
that perform a most recent price lookup on a security (stock):

-- MAIN PROGRAM price_pg.adb

with Ada.Text_IO;
with APQ.PostgreSQL.Client;
with Prices;

use APQ, Prices, APQ.PostgreSQL.Client, Ada.Text_IO;

procedure Price_PG is
    C : Connection_Type;
    P : APQ_Double;
begin

    Set_DB_Name(C,"myuserid");
    Connect(C);

    Last_Price(C,"RHAT",P);
    Put_Line("RHAT $" & APQ_Double'Image(P));

    Disconnect(C);

end Price_PG;

--- Package prices.adb

package body Prices is

    -- CREATE TABLE PRICE_HIST (
    --    SECURITY   CHAR(10) NOT NULL,
    --    PRICE_DATE DATE NOT NULL,
    --    PRICE      REAL,
    --    PRIMARY KEY(SECURITY,PRICE_DATE)
    -- );

    procedure Last_Price(
       C :        in out Root_Connection_Type'Class;
       Security : in     String;
       Price :       out APQ_Double
    ) is
       function Value is new Float_Value(APQ_Double);

       Q : Root_Query_Type'Class := New_Query(C);
    begin

       Prepare(Q,     "SELECT SECURITY,PRICE_DATE,PRICE");
       Append_Line(Q, "FROM PRICE_HIST");
       Append(Q,      "WHERE SECURITY = ");
       Append_Quoted(Q,C,Security,Line_Feed);
       Append_Line(Q, "ORDER BY SECURITY,PRICE_DATE DESC");

       if Engine_Of(C) = Engine_MySQL then
          Append_Line(Q,"LIMIT 1");  -- Use this if the database is MySQL
       end if;

       Execute(Q,C);

       begin
          Fetch(Q);
       exception
          when No_Tuple =>
             raise;      -- APQ.No_Tuple indicates no price
       end;

       Price := Value(Q,3);

    end Last_Price;

The above program was written to be database agnostic, though
it does use PostgreSQL. This is chosen by the WITH statements
in the main program. Notice how the Last_Price function
adds "LIMIT 1" to the query if it is using MySQL. This helps
the performance of the query, since only 1 row is required
for this routine.

The Prices package is completely database agnostic. The
spec for it is written as follows:

    with APQ;
    use APQ;

    package Prices is

       procedure Last_Price(
          C :        in out Root_Connection_Type'Class;
          Security : in     String;
          Price :       out APQ_Double
       );

    end Prices;

So if database portability is also important to you, you might
consider APQ. All database access is object oriented in APQ.

A number of debug and trace facilities also help your development.
You can capture every SQL query performed to a trace file. This
saves a great deal of time when you need to troubleshoot.

Those are just some highlights. If you want to find out more,
visit my home page below and follow the APQ links.

Thanks for allowing me to bend your ear ;-)

Warren.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada & Postgresql

[Michael Erdmann]

Warren W. Gay VE3WWG wrote:
> Wojtek Narczynski wrote:
> 
>> Hello,
>>
>> We used APQ, with MySQL, but PostgreSQL was its primary database, and
>> found it to be very high quality, with outstanding documentation.
>>
>> Regards,
>> Wojtek
> 
> 
> One of the primary reasons for me to write APQ was to make it as easy
> as it can be to use a database from Ada, without discarding strong
>......
> My biggest concern however is always application deployment. I can
> make just about anything work for myself. Making an open sourced
> package easy for someone else to install and use is more difficult.
> This is the main reason I stayed away from UNIXODBC. This is less
> of an issue on Windows, but I never really felt that ODBC was the
> way to go anyway. APQ only requires GNAT, and the database software
> client libraries (libpq or the mysql libraries). This makes it
> much easier to deploy than GNADE for example.

THis confusyse me a litle bit. On Windows ODBC work within
some Minutes (on Linux it takes mutch longer).

What is so difficult to deploy?

Regards
     M.Erdmann

Re: Ada & Postgresql

[Pascal Obry]

Michael Erdmann <michael.erdmann@snafu.de> writes:

> THis confusyse me a litle bit. On Windows ODBC work within
> some Minutes (on Linux it takes mutch longer).
> 
> What is so difficult to deploy?

On GNU/Linux Debian that's quite easy!

You have too add the proper ODBC support packages:

   $ apt-get install odbc-postgresql
   $ apt-get install unixodbc
   $ apt-get install unixodbc-dev

Then you need to register your DSN in ~/.odbc.ini. That's all. I agree that
it is a bit easier on Windows but not that much I would say...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Ada & Postgresql

[Warren W. Gay VE3WWG]

Pascal Obry wrote:
> Michael Erdmann <michael.erdmann@snafu.de> writes:
>>THis confusyse me a litle bit. On Windows ODBC work within
>>some Minutes (on Linux it takes mutch longer).
>>
>>What is so difficult to deploy?
> 
> On GNU/Linux Debian that's quite easy!
> 
> You have too add the proper ODBC support packages:
> 
>    $ apt-get install odbc-postgresql
>    $ apt-get install unixodbc
>    $ apt-get install unixodbc-dev
> 
> Then you need to register your DSN in ~/.odbc.ini. That's all. I agree that
> it is a bit easier on Windows but not that much I would say...
> 
> Pascal.

Debian is fine for those using it. But what about *BSD, Solaris and
HP-UX users for example?

Things have probably improved a lot since I started APQ. Documentation
for instance. At the time, I recall that documentation was one big
issue I had with UNIXODBC.

A big problem for me at the time was that it failed to install
on FreeBSD (I don't recall if this was UNIXODBC and/or GNADE).
Anyway, I couldn't live with it being broken there, and was
too busy to fix/get it fixed. And worse, I didn't want to spend
time helping other users to fix their problems with it, just
so that they could run any database applications I might write.

APQ only depends upon the database product, and thus installs
more readily on a variety of platforms. As I said to Michael
Erdmann in an email, at the time, I was prepared to use someone
else's hard work. Portability is very important to me however,
and I need something that works not only on Linux, but *BSD,
HP-UX, Solaris etc. This is the reason I have invested my time
in APQ.

Warren.

Re: Ada & Postgresql

[Ludovic Brenta]

"Warren W. Gay VE3WWG" writes:
> Debian is fine for those using it. But what about *BSD, Solaris and
> HP-UX users for example?

They should use Debian, "The Universal Operating System" :)

Just joking.

-- 
Ludovic Brenta.

Re: Ada & Postgresql

[Benjamin Ketcham]

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> Pascal Obry wrote:
>> 
>> On GNU/Linux Debian that's quite easy!
>> 
>>    $ apt-get install odbc-postgresql
>>    $ apt-get install unixodbc
>>    $ apt-get install unixodbc-dev
> 
> Debian is fine for those using it. But what about *BSD, Solaris and
> HP-UX users for example?

The nice thing about Debian .deb packages is that they are actually
just old-school "ar" archives.  "ar -x", then you are left with
a few regular tar.gz files and an install script (which you may
wish to read, rather than run).

Of course, you'd want to grab the source, rather than the binary,
packages.  And extracting the files is of course only the first
step; whether the code is actually portable to those other platforms
is a completely different question...

--Benjamin

Re: Ada & Postgresql

[Warren W. Gay VE3WWG]

Benjamin Ketcham wrote:
> Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> 
>>Pascal Obry wrote:
>>
>>>On GNU/Linux Debian that's quite easy!
>>>
>>>   $ apt-get install odbc-postgresql
>>>   $ apt-get install unixodbc
>>>   $ apt-get install unixodbc-dev
>>
>>Debian is fine for those using it. But what about *BSD, Solaris and
>>HP-UX users for example?
> 
> The nice thing about Debian .deb packages is that they are actually
> just old-school "ar" archives.  "ar -x", then you are left with
> a few regular tar.gz files and an install script (which you may
> wish to read, rather than run).

That is a nice way to do it.

> Of course, you'd want to grab the source, rather than the binary,
> packages.  And extracting the files is of course only the first
> step; whether the code is actually portable to those other platforms
> is a completely different question...
> 
> --Benjamin

Which was really my point. It is easier to get users up and running
with fewer prerequisites than many. Advanced users can work through
most issues with enough patience (though not all have the time or
patience ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg