Re: Best Procedural Language?

I'd say that the biggest benefit of pl/pgsql for postgres is that it is
so close to Oracle's own procedural language. This makes the job of
porting from Oracle to postgres *nearly* trivial.

Convincing a site to switch from Oracle to Postgres is therefroe easier
and a major feather in postgres's cap.

Working with both Oracle 8,9,10 and postgres 7.4 and 8, I find switching
between the two dbs fairly easy. Oracle is richer in terms of
(programming) features but bang for buck and ease of
administration/setup etc, you just can't beat postgres...

John

Merlin Moncure wrote:
> On 8/1/06, Christopher Browne <cbbrowne(at)acm(dot)org> wrote:
>
>> Martha Stewart called it a Good Thing when "Carlo Stonebanks"
>> <cstonebanks(at)nissenfasteners(dot)com> wrote:
>> > I am interested in finding out a "non-religious" answer to which
>> > procedural language has the richest and most robust implementation
>> > for Postgres. C is at the bottom of my list because of how much
>> > damage runaway code can cause. I also would like a solution which is
>> > platorm-independent; we develop on Windows but may deploy on Linux.
>
>
> my take:
> C:
> you can probably get by without doing any C. Most (but not quite all)
> of things you would do via C is exposed in libraries. One thing you
> can do with C for example is invoke a function via its oid and
> manually supplying parameters to make callbacks for proceures. you
> can also dump core on your backend. good luck!
>
> pl/pgsql:
> you do not know postgresql if you do not know pl/pgsql. period. ideal
> for data processing and all sorts of things. all queries are first
> class in the code (except for dynamic sql), which in my estimation
> cuts code size, defect rate, and development time about 75% for
> typical database type stuff. just be warned, after you learn it you
> will never want to use another database ever again, i'm not kiddig.
>
> pl/perl, etc:
> not much to add beyond what chris browe said: great for text
> processing or library support.
>
> merlin
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org