From: "Josh Berkus" <josh@agliodbs.com>
Subject: Re: 16 parameter limit
To: John Proctor <jproctor@prium.net>
Cc: pgsql-sql@postgresql.org
Date: Fri, 05 Apr 2002 08:46:29 -0800
Message-ID: <web-1050317@davinci.ethosmedia.com>
In-Reply-To: <200204042228.g34MS7a28755@slxmail01.prium.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit

John,

>    Thanks for replying.   I fear that I may have come off as whiny or
>  
> ungrateful.  I hope that I did not.   I am extremely happy with
>  PostgreSQL 
> and would like to see it take root in enterprise business.   

Sorry.  I tried to seperate my criticisms of the people you were
 talking about (e.g. Oracle DBAs who can't be bothered to read the
 mailing list) and you (who obviously *can* be bothered to read the
 mailing list).  Maybe *I* wasn't clear enough.

>I work
>  with 
> oracle, sybase and mssql every day.   Oracle is a nice database, but
>  it is 
> expensive and I am not interested in their new direction (Java this,
>  Java 
> that).   9i has about 2GB of jar files that I don't even want or
>  need, but I 
> still have to back them up because I am afraid to delete them.

Hey! I like Java, personally.  It's just that I don't often get
 projects that are more intersted in comprehensive design as they are
 in cost savings ... thus I do a *lot* of PL/pgSQL + PHP combinations.

>    Anyway, I understand your point about using a 3GL for the middle
>  tier data 
> access, but I don't see that happening on large projects.   I know
>  there are 
> many java projects that did that and still do, but I haven't seen
>  many that 
> worked out well.   Most large projects that I have seen and I am
>  involved in 
> use a complete stored procedure interface.  The reasons are simple.
>    The 
> DBAs can design the database and provide the interface.   The
>  developers only 
> need to understand the interface exposed by the DBA (stored procs).
>    It also 
> allows for multiple languages to use the same interface, which is
>  very 
> important when integrating with legacy systems.   Also, compiled
>  PL/SQL runs 
> much faster than java/jdbc, and is much faster to develop and debug.
>    I can 
> also minimize bugs by not allowing developers to write directly to
>  tables.   
> I know that if my procedure interface is correct and few changes are
>  needed 
> to the data layer then changes to the display layer do not effect the
>  
> database.   However, this same logic does not seem to hold well with
>  the 
> middle layer.   Middle layers tend to follow changes in the display
>  layer 
> which increases potential for bugs.

Well, that's not the theory of n-tier development, but I'll agree that
 real, CORBA-compliant business objects are seldom implemented properly
 outside of (perpetually unfinished) Open Source projects.  Certainly
 the advantage of a SQL scripting language is that the person who
 understands the database best (the DBA) can implement business rules
 without learning a completely different programming lanuguage.  This
 was the reason for the termendous popularity of 4GL in its day (BTW,
 there is a 4GL interpreter for PostgreSQL).

> It has been my experience that most large oracle projects done by
>  good 
> professionals use PL/SQL extensively.   That is why I think
>  PostgreSQL will 
> not penetrate this market unless it can allow developers to continue
>  using a 
> model that has proven to be successful.

Yup.  You gotta do what the customers want, or you don't capture them.
  Let me also reiterate my statement that I believe that Great Bridge
 made a mistake trying to take on Oracle last year, and that Red Hat is
 more astute going after the MS SQL market.

> Please note that I am not someone just sitting around waiting for
>  others to 
> spend their time building my needs.   I am involved in some other
>  projects 
> regarding open source.   I am also not complaining.   I just didn't
>  want 
> people to think that lack of questions regarding this meant lack of
>  need in 
> large companies.   It is just that those people are not even looking
>  at 
> PostgreSQL right now.   My only reason for bringing it up is my
>  desire to see 
> PostgreSQL move forward and so that I may (for selfish reasons) use
>  it in 
> some professional projects one day.

See my first paragraph.

If you want to pursue this (and I wish you would!) there's two ways to
 go:

1. Try to get the current major commercial PostgreSQL implementation,
 Red Hat's RHDB, interested in your suggestions.  Michael Evans at Red
 Hat is in charge of RHDB.  As far as I know, however, all of their
 development effort is cocentrated on the issues of replication, user
 interface, and backup/recovery.

2. Work with me and other PL/pgSQL users to develop a laundry list of
 PL/pgSQL improvements, and then recruit or hire a programmer or
 programmers to implement them.  I would be happy to contribute specs
 and testing to such a project, but I don't know enough C to do
 anything useful.  Preferably, we would find someone interested in
 being the ne PL/pgSQL lead so that the language can continue to move
 forward indefinitely with a strong advocate and targeted goals for
 every Postgres release.

-Josh Berkus