Re: 16 parameter limit

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 weretalking about (e.g. Oracle DBAs who can't be bothered
toread themailing list) and you (who obviously *can* be bothered to read themailing 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 getprojects that are more intersted in comprehensive design
asthey arein 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 thatreal, CORBA-compliant business objects are seldom
implementedproperlyoutside of (perpetually unfinished) Open Source projects.  Certainlythe advantage of a SQL scripting
languageis that the person whounderstands the database best (the DBA) can implement business ruleswithout learning a
completelydifferent programming lanuguage.  Thiswas the reason for the termendous popularity of 4GL in its day
(BTW,thereis 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
believethat Great Bridgemade a mistake trying to take on Oracle last year, and that Red Hat ismore astute going after
theMS 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 togo:

1. Try to get the current major commercial PostgreSQL implementation,Red Hat's RHDB, interested in your suggestions.
MichaelEvans at RedHat is in charge of RHDB.  As far as I know, however, all of theirdevelopment effort is cocentrated
onthe issues of replication, userinterface, and backup/recovery.
 

2. Work with me and other PL/pgSQL users to develop a laundry list ofPL/pgSQL improvements, and then recruit or hire a
programmerorprogrammers to implement them.  I would be happy to contribute specsand testing to such a project, but I
don'tknow enough C to doanything useful.  Preferably, we would find someone interested inbeing the ne PL/pgSQL lead so
thatthe language can continue to moveforward indefinitely with a strong advocate and targeted goals forevery Postgres
release.

-Josh Berkus