From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Ada package registry?
Date: Fri, 5 Feb 2016 16:53:58 +0100
Organization: A noiseless patient Spider
Message-ID: <n92gda$725$1@dont-email.me>
References: <02241ec4-0f95-4f63-9abc-092f167eb59e@googlegroups.com>
 <56af17b7$0$301$14726298@news.sunsite.dk> <n8n8ib$sqr$1@dont-email.me>
 <56b06eb8$0$301$14726298@news.sunsite.dk> <n8rcp6$f93$1@loke.gir.dk>
 <1454483747.2785.135.camel@obry.net> <n8ttvb$se2$1@loke.gir.dk>
 <n8vvfk$ml3$1@dont-email.me> <n90022$tgm$1@gioia.aioe.org>
 <n901l6$b7$1@dont-email.me> <n90fcu$rnk$1@loke.gir.dk>
 <n925rt$th2$1@dont-email.me> <n9280s$9es$1@gioia.aioe.org>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 5 Feb 2016 15:51:06 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="b96887e80893c84a90c3007226ca0d1c";
	logging-data="7237"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19YrA2TPg7rSQG/SL5ZASKn92tl9HOOZGo="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.5.1
In-Reply-To: <n9280s$9es$1@gioia.aioe.org>
Cancel-Lock: sha1:eUXyGhizQd9XK2Ww18Yjc+OoenM=
Xref: news.eternal-september.org comp.lang.ada:29361
Date: 2016-02-05T16:53:58+01:00
List-Id: <comp.lang.ada>

On 05.02.16 14:27, Dmitry A. Kazakov wrote:
> On 05/02/2016 13:54, G.B. wrote:
>
>> Using a relational DBMS with competitive Ada could like this:
>>
>>      with Ada.ODBC;
>>
>> and since SQL knows cursors, the Ada type system could provide
>> for a corresponding standard Cursor type, etc.
>
> No, it cannot. Cursor in ODBC is invisible, which is a source of
> countless errors because operations implicitly create, remove, change
> the cursor.

The correspondence between DBMS cursors and Ada cursors
need not be that of being identical. It is supposed to be of
a behavioral nature:
You get a result set, then look at the tuples in the result
set one by one. These notions can be mapped to both, either SQL,
or to Ada.Containers.

It is just annoying to have common and widespread notions,
such as looking at elements of a set of tuples one by one,
but nothing in Ada to meet these requirements both portably,
and easily when the tuples are coming from something that
is as unusual as an RDBMS!

>> Also, SQL-invoked routines should be dead easy to write in Ada
>> using just the language and library of Ada.
>
> You mean RA, stored procedures or statement execution?

I mean "SQL-invoked routines", just the technical term of SQL.
ODBC is not necessarily involved, here. An Ada subprogram is being
called by the MS part of the DBMS, logically from within some
SQL statementent. As is done with stored procedures written in
SQL. E.g., when evaluating an expression, the DBMS passes database
values to an Ada function; when CALL-ing an Ada procedure, it
might expect the procedure to place a result into some IN OUT
parameter, or it might call the Ada procedure just for its effect.

One thing that is realistically needed, then, is a mapping from
vanilla RDBMS's system defined types to Ada types. Not hard to
do, I imagine, in Ada's Interfaces.* hierarchy.