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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.224.68.72 with SMTP id u8mr5379500qai.1.1399652782485; Fri, 09 May 2014 09:26:22 -0700 (PDT) X-Received: by 10.182.104.131 with SMTP id ge3mr11065obb.39.1399652782380; Fri, 09 May 2014 09:26:22 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!ih12no1932708qab.1!news-out.google.com!gi6ni796igc.0!nntp.google.com!r10no2440329igi.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 9 May 2014 09:26:22 -0700 (PDT) Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=71.219.231.11; posting-account=X7Y-0AoAAABSgWfgVpaegSDud7e4NIYx NNTP-Posting-Host: 71.219.231.11 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <304f2721-64bc-4959-a7e8-0cc29cf5204f@googlegroups.com> Subject: Ada and PL/pgSQL ? From: sdalemorrey@gmail.com Injection-Date: Fri, 09 May 2014 16:26:22 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:19763 Date: 2014-05-09T09:26:22-07:00 List-Id: After careful review the most frequent and essential logic functions of thi= s exchange application directly as a collection of stored procedures, funct= ions and triggers in the Postgres database that will be backing it, seems t= o make the most sense. The logic behind the decision is pretty clear cut. Transit time back and f= orth between the database becomes cumulative and burdensome when you consid= er just how many queries are involved. By way of example, we have a transactions table and an orders table. Befor= e an order can be placed, the transactions table must reflect a debit again= st the user account by the amount of their bid by way of a special "HELDFOR= ORDER" flag that otherwise looks like a normal withdrawal transaction. The= n once the order is settled, that flag must be changed to DEBIT. Thusly even a simple market order consists of several round trips to the da= tabase, unless the logic can be consolidated into a collection of functions= that are stored in the DB. Overall an order looks like this.. Step 1: Check user balance and ensure it is sufficient to cover the order Step 2: Hold funds for order Step 3: Create Order Step 4: If market order or FOK then trigger the order matching engine. Step 5: Attempt to fill orders by comparing bid/ask and matching them. Step 6: Convert transaction hold flag to debit and link in the orderID. Under the original system, each of these steps were at least one round trip= between application core logic (a mix of PHP and C) and the DB (which was = originally level and then moved to MySQL). The minimum execution time for = an order was 30s. However it was climbing as high as 5mins. About 20% was = query and transit time. With a majority of the slow down occuring from tab= le locks on db transactions. Thus the decision to move that logic closer to the datastore, embedding it = if at all possible.=20 While researching the PL/pgSQL language I noticed that it bears a shocking = similarity to Ada. Almost like it's Ada but tailored for SQL. Still I would like to maintain the safety and provability of Ada. It appears that Postgres has the ability to import various languages such a= s C and execute those about as easily as it's own native language. So the question I have here is, does anyone know of a path to get Ada funct= ions operational in Postgres. Or (assuming there is a pathway) is Postgres= 's PL/pgSQL going to give the same benefits of Ada? =20 The languages are to my mind so similar that I'm having real difficulty see= ing a major difference between the two. Thanks for any info!