> The major disadvantage is that the development environment and tools for
> in-database languages aren't nearly as rich as your typical standalone
> environment, which makes programming a pain in the ass for many types of
> codes. I might have missed something in the intervening years, but I
Although the gap still exists within the environment itself, one
significant advantage with PostgreSQL is you can use a more native (to
the programmer anyway) language to generate your logic.
With PostgreSQL alone you can use plPerl, plPython and plPHP. The
language itself hasn't change in it's implementation of the pL. You just
have to remember to make all ' a '' :) (at least for the most part).
Sincerely,
Joshua D. Drake
> don't think anyone has really bridged that gap. The database guys
> generally don't like running application code in their database, mostly
> because it creates new failure modes and problems that they have to
> manage. For example, at least in older versions of Oracle, if you
> accidentally programmed an infinite loop or some other busy
> non-functioning state, it took the DBA to kill it. In the course of
> application development, this could happen many, many times as code was
> being debugged, much to the annoyance of the DBAs.
>
> That said, I don't see any obvious reason why it couldn't be done well
> with a moderate amount of effort.
>
>
> j. andrew rogers
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
