Обсуждение: How can we help?

Hi all!

Sorry for the length of this but I'm trying to get an idea of where my
company can contribute to the best effect so I have a number of questions.

To begin with my team and I have some energy/time/$ over the coming months
to put directly into PostgreSQL-related development work. Technical Pursuit,
has made a commitment to PostgreSQL for both our internal projects and our
customer projects. We've been evangelizing PostgreSQL for a while now (I did
a talk on it at the Database Discovery cruise last June in Alaska -- a lone
voice in literally a sea of Oracle folks) and have started doing
Oracle-to-PostgreSQL conversions for customers wishing to transition away
from Oracle. We're also getting ready to ship a beta release of our TIBET
product that uses PG as the backend source code repository among other
things.

Areas we have customer/business needs in include replication,
backup/recovery, monitoring/control, XML support, HTTP/HTTPS protocol
support for postmaster, pl/pgperl, possible pl/jython, and possible
compile-time inclusion/configuration of time-travel (--with-time-travel ?).

On the process side, is there an IRC or other chat-based system in place for
the PG team to coordinate their efforts? If not, would an IRC system hosted
by TPI be something folks would be interested in using? We'd be willing to
start hosting a set of IRC channels if that would assist the team and the
community in support issues etc.

For XML support I've contacted John Gray who did the current XML contrib but
has since ceased development and he's granted me permission to pick up where
he left off to improve XML support as it relates to his contrib module. Is
there any move underway to integrate XML with PG at any other level?

If we were to contribute to replication/backup/recovery solutions who would
we coordinate that effort with? If that's something the core team is on top
of, can we get an idea of what is expected by August so we can advise our
customers and plan accordingly?

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? We're looking seriously at the
idea of a pl/jython that would leverage the Jython language to provide
scriptable Java procedures in the engine. Any feedback on that idea?

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. We've got a simple perl "bridge" that performs this task now and
the performance is more than adequate but we're sure it would be even better
if we could avoid having the separate perl component. Is there any interest
in this elsewhere? Any feedback on how/where we should start other than
hacking postmaster? ;)

What is the current thinking on re-introducing time-travel support, perhaps
as a compile-time feature ala --with-time-travel? This is a feature our
customers would get significant financial benefit from. I've seen recent
notes that this might be possible to do. We're *extremely* interested in
this direction given the potential for differentiation from other products
in the marketplace. It would strengthen PG significantly in our mind.

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 so, how do
we get involved? PG/Financials anyone?

Again, sorry for the length of this and the raft of questions. I hope you
understand we're in a somewhat interesting position with some time and $ to
focus on PG, particularly as it relates to replication/recovery issues. Any
guidance on how we can put that to work for the community would be
appreciated.

Thanks.

ss


Scott Shattuck
Technical Pursuit Inc.

On Fri, 7 Jun 2002 17:43:03 -0600
"Scott Shattuck" <ss@technicalpursuit.com> wrote:
> On the process side, is there an IRC or other chat-based system in place for
> the PG team to coordinate their efforts?

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

> If we were to contribute to replication/backup/recovery solutions who would
> we coordinate that effort with?

There are a number of replication efforts, each attempting to provide
various levels of functionality. The PGReplication project
(http://gborg.postgresql.org/project/pgreplication/projdisplay.php) is one
of the more ambitious ones; others include PGReplicator, DBMirror,
rserv/erserv, and probably more that I'm not aware of.

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?

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

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

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

Cheers,

Neil

-- 
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

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.

Le Samedi 8 Juin 2002 01:43, Scott Shattuck a écrit :
> 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?

You may be interested in looking at PLjava on
http://sourceforge.net/projects/pljava/

Cheers,
Jean-Michel POURE