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 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