Re: How can we help?

First of all thanks for the feedback!

> There's #postgresql on efnet and irc.openprojects.net, but it's mostly
used
> for user support.
>

The offer for development coordination channel(s) stands if other folks are
interested.

...snip...

>
> I can't speak to the backup/recovery efforts -- since there seems
> to be less activity in this area, perhaps this would be an appropriate
> place for Technical Pursuit to focus on?
>

We'd be happy to if others agree. I'll post a separate message trying to
summarize what I understand of the current backup/recovery items on the TODO
list and looking for input.

> > What is the planned status of Java support in the engine? Is there
anyone
> > working on JVM integration at this stage and if not, how could we best
> > integrate with the team to take on this task?
>
> http://pljava.sourceforge.net/ is the only project that I'm aware of.
>

I hadn't found this. Thanks.

> > For several scenarios we see value in having the postmaster respond to
> > http(s) protocols and relay to internal functions for processing of web
> > traffic.
>
> Perhaps you could elaborate on this? It sounds like bloatware, but maybe
> I'm just cynical.
>

OK. But remember you asked for it :).

Given a market which seems bent on HTTP(S)-based XML/SOAP access to data and
XSchema/XML output it seems natural to consider putting these into PG. The
buzzword seems to be XML Databases. I'm not a big subscriber to that concept
so don't get me wrong, I'm not looking to go that route, but I do see value
in unifying the protocols for data access so PG can be a fully qualified
player in the game.

In one sense, we're trying to use PG as we think it was designed, not as a
database server so much, but as an application server. Smart databases don't
need app servers -- they are app servers. The problem is, web apps need
HTTP(S) support. So, we're thinking we'd create new "listeners" for PG that
add alternative protocol support. We've done a simple HTTP listener in Perl
that hands off to the postmaster process and while I hesitate to publish any
raw data at this point let's just say that even with the extra overhead of
the Perl the results are enlightening.Web servers aren't the only things
built to scale under load and our tests show that the team working on PG has
done a great job.

Our business case is simple. We want to avoid having to ship a combination
of Apache, Tomcat, and PostgreSQL to our customers. While a lot of products
need a database and web access do they really need to ship with a manual
that tells the customer to configure Apache, Tomcat, and PG and make sure
they all start up and stay up? We'd like to reduce that complexity.

The complexity of today's web designs is what I'd define as "bloatware".
But, rather than referring to a single product, my definition applies to the
combination of technologies currently required just so we can put a web face
on our database. Web server, servlet container, J2EE server, database.
That's bloat.

Why use PG at all if we're not going to use it for what it was designed from
day one to do? Namely, support writing applications directly in the database
itself. Given current web architecture I'm sure some might say I'm crazy to
consider such a thing and I have two words for them -- Oracle Financials.

Oracle has made billions off the design I'm talking about. Oracle Financials
isn't written in Java and it doesn't need 3 servers and 500 jar files from
the Jakarta project (although with 9i who knows ;)). It's written in plsql.
If stored procs can do all that in a database that wasn't even designed to
be extended for application support they can certainly parse a GET/POST
request. I just need the postmaster to listen for HTTP so it can figure out
which proc to call on my way to replacing 5 years of web bloatware ;).

> > Finally, we're starting to do a lot of work in pl/pgperl(u) and are
> > wondering whether that's an area we can again contribute in.
>
> If you mean plperl, then I don't see why not ; if you're talking about
> a new procedural language based upon some unholy union of pl/pgsql and
> perl, I'd be skeptical :-)

Allowing perl programmers to think in perl full time and use interfaces
they're familiar with is more our goal. Something like a DBI module that
would function as if you were external to PG even though you aren't. Write a
stored proc as if it were going to run outside of the database. Install it
inside when it makes sense. No code change. We should be able to say "if you
know perl/DBI you know how to write stored procs for PG". Same for
pl/python. Same for Jython. I don't know if we can get there from here but
it's a goal we're going to work hard for.

ss

Scott Shattuck
Technical Pursuit Inc.