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