Skip site navigation (1) Skip section navigation (2)

Re: Stored procedures in C

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Martin Gainty" <mgainty(at)hotmail(dot)com>
Cc: "Emiliano Moscato" <moski666(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Stored procedures in C
Date: 2008-04-24 14:48:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
On Wed, Apr 23, 2008 at 6:38 PM, Martin Gainty <mgainty(at)hotmail(dot)com> wrote:
> Emiliano and Mike
> The real challenge is trying to determine what a datatype is in cobol..for
> that matter what is stack variable or heap in Cobol?
> In the end you're better off <re>writing this mess (preferably in Java)..
> unless of course you need the billable hours for
> the first rewrite to C
> then later rewrite to Java

(have no idea how this relates to the OP's original question).  If you
are trying to port a cobol app to postgres, your best bet is to go
through the client interface, libpq.  If you had to do it on the
server side, I would stick to cobol environments that are C ABI
compatible.  Writing general purpose data procedures in C is just not
a very good idea most of the's difficult and dangerous...C
SPI has great uses, it's just not for everything.

I personally think cobol is better suited for data processing type
problems than java.  Mapping cobol data types to SQL is not terribly
difficult.  cobol is notoriously difficult to port to another
langauges...probably cheaper to connect it to the database via ISAM
wrapper if the app is over a certain size.  Many modern cobol
environments support external data sources through various
techniques...extfh for example.  AcuCobol (crypticly) allows linking a
ISAM emulation layer directly to the cobol runtime, one approach I've
used in the past.


In response to


pgsql-general by date

Next:From: Tom LaneDate: 2008-04-24 14:52:28
Subject: Re: error connecting to database: could not open relation
Previous:From: Erik JonesDate: 2008-04-24 14:21:22
Subject: Re: Best backup setup

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group